With the recent string of high-profile software project failures, from the Healthcare.gov website to the Target / Home Depot data breaches – in many cases caused by a lack of planning, understaffed teams, or underperforming project managers and architects, the field is ripe for creation of a regulatory body to provide guidance and ensure compliance to development standards. While the actual implementation of a wide-reaching government-sponsored regulatory system is still at least a decade away, the early stages of such a system are already becoming apparent in both business and technology.
Over the past ten years, IT systems and development projects have become increasingly regulated in many industries. The healthcare industry implemented HIPAA, credit card processing implemented PCI, and public companies have come under governance of SOX. Standards abound to help structure the development of software, from IT frameworks such as COBIT, to fine-grained practice recommendations such as ITIL.
In addition to the government and industry regulations, certifying bodies abound in the IT industry, providing “proof of education.” Microsoft markets their Partner program, Google and Apple provide smaller-scale certification, and Cisco has made their certification program a key business differentiator. Even universities fall under the umbrella of certifying bodies, providing proof of completion of a degree, and successful completion of a software development curriculum. The drawback of certification, however, is that although the certifying bodies to provide an indicator of past knowledge, they do not provide any guarantees on application of that knowledge.
In addition to IT frameworks, standards and best practices are becoming increasingly popular. From development methodologies such as Agile and Test-Driven Development, to general guiding principles such as Standards Oriented Architecture, best practices provide guidance for development challenges. In addition to best practices, software development patterns are helping to create a unified vocabulary for discussion of design, and defining the elements that make maintainable and scalable systems.
In contrast to all of these forces, however, certain areas of the software development process are tearing away from any set standard. While some projects can be easily defined, others require an agile and collaborative approach. Software developers can often be considered artists or consultants, creating something new and unique. Portfolios and case studies are the primary working means of accreditation, as opposed to licenses and stamps of approval. The newer the technology, the more youthful and poignant the development spirit. Still, as the regulatory requirements and standards take hold, it is only a matter of time before the brazen wild west of software development turns into the civilized state of California.
So what would a “license to code” look like? And how would the software approval process be implemented? One possible regulatory system might look like this:
- User Requirements
- – Reviewed by Authority
- System Architectural Plans (Including Design Documents, Testing Plan)
- – Reviewed by Authority
- Development Work
- – Final Review by Authority
- Error logging and support issue tracking
- – Yearly / Periodic Maintenance Reviews
Since most of friction in software development results from unclear and changing business requirements, a critical step to ensuring successful completion of software projects would be to require concrete user requirements. For smaller projects, the requirements could primarily consist of use-cases describing what the software needs to accomplish. Once these would be defined at the beginning of the project, they would not be subject to change without restarting the approval process.
With the requirements reviewed by an authority for completeness, the next step would be the creation of the system architecture plans. An architect would develop the design documents, including a description of development methodology, project management procedures, team members, and testing plans. The architect would first present and receive approval from the project stakeholders that the new designs will meet their requirements, and then submit them to the regulatory body. Upon review and approval of these documents, the team would have the go-ahead to begin development.
As in construction projects, the development work might have additional checkpoints or reviews to make sure the development work is proceeding properly. Testing procedures might be reviewed, and security implementations analyzed for vulnerabilities. Upon completion of the work, a final comprehensive system analysis could be performed, with a combination of both automated and manual tests, gauging error handling, susceptibility to memory leaks, and successful completion of the test cases.
Finally, as the project enters the maintenance cycle, the inspector would receive a yearly review of error logs and support issues to see if certain problems might be indicative of larger-scale system failures. The yearly reviews could also consist of automated vulnerability testing, and industry-specific standards compliance.
If the overhead in a “License to Code” seems high, it certainly is. Perhaps the overhead and stringent guidelines would strangle almost all entrepreneurship and creativity out of the industry, and increase software costs. Still, as the software industry becomes increasingly mature, standards will abound, and both development companies and their clients will look for ways to ensure successful completion of their software projects.
Written by Andrew Palczewski
About the Author
Andrew Palczewski is CEO of apHarmony, a Chicago software development company. He holds a Master's degree in Computer Engineering from the University of Illinois at Urbana-Champaign and has over ten years' experience in managing development of software projects.
Google+
