Developing any product requires the 3 Bs:
- Builders
- Building processes
- Building blocks & tools
Let’s analyze in more detail these three aspects of development in the context of technology. Progressively, over the past couple of decades, it has become common place for organizations to have an IT department, which may still be perceived as a necessary evil by the business side due primarily to less than readily available statistical quantitative reporting on their value add, but that’s a topic for another discussion. IT departments often have to help decide between build versus buy, which may not always be as rigorous a process as it should due to political considerations and management leaning in one direction or another. That’s also topic for another discussion. So, let’s analyze the echo system for in-house software development.
Builders are the most important of the 3B’s, simply because the blocks and the processes are not yet autonomous. There are several aspects to software development that require various combinations of specific training, knowledge, and experience. These skill-sets requirements may be consolidated into the following 8 functional areas:
- [BA] Analyze the business process to produce concrete and transferable (parameters and constraints hand-off) requirements
- [Arch] Architect a relevant solution with, at the very least, a data flow and a components model
- [Tech lead] Design the constituent components, their relationships, and public interfaces and lead the development effort
- [Developer] Develop, deploy, enhance, and maintain the codebase
- [Tester] Test the codebase and the product against the parameters and constraints identified in the business analysis
- [Technical writer] Develop help documentation and support specification
- [UX] Progressively improve all aspects of the process and the product, focusing primarily on product usage efficiency
- [PM] Manage the process instance, e.g., the project, quantitatively with sponsor directives, communications, tasks, risks, etc.
There’s a tendency in the industry to delegate large portions of the process components requiring special skills to developers with certain levels of exposure to pre-identified tools and platforms. Development cost containment is by far the most frequently identified underlying cause for such inclinations. However, a minor analysis takes that argument apart and obviates such to be a misconception. It’s true that developers are generally highly intelligent individuals and can deduce and acquire sufficient expertise to cover all of the 8 identified functional areas. It is also true that the overall hourly development cost of a non-ideal team (say, 3 developers with the help of some actual or sample end users) developing a software is less than that of an ideal team (team of 8+ specialists, 1 or more specialist from each of the 8 identified functional areas) doing so. While hourly development cost is an important piece of information highly visible and easily attained and plugged into cost justification reporting, other less quantifiable expenses must be quantitatively/statistically analyzed or extrapolated into account at the very least, because the costs are present whether they are measured or not. Consider for example, the negative impact of a non-ideal development team:
- Developers managing projects without specific training
- Lower the quality of project management output (easy to learn, requires sustained training to master), proportionally raising timeline and corresponding development hours
- Raise the risk of task failure, because one of the most important, although frequently skipped, responsibilities of a PM is to progressively breakdown tasks until associated risks may be quantified and used to project estimated development hours, which would be negatively impacted
- Raise the risk of project failure, potentially due to reactive management and communication lapses
- Developers architecting/designing solutions without specific training
- May be unable to form sound basis for reasonable component models and/or well encapsulated interfaces contributing negatively to the 4 pillars of software: security, scalability, performance, and maintainability, consequently raising TCO by orders of magnitude at multiple levels
- Developers moonlighting as BAs (testers, technical writers, or usability experts) without specific training
- Raise the unit cost of business analysis, because they generally have higher hourly rate
- Lower the quality of analysis output (BA is easy to learn but takes sustained training to master), proportionally raising development timeline and TCO
Having ideal teams alone is no guarantee for success, they must be accompanied by continuous training focused corporate strategy and a solid development process.
A better trained team member makes better decisions, resulting in better product quality, resulting in lowered TCO and higher productivity, contributing directly to corporate bottom-line.
The second leg of a team building strategy is the development methodology (building process), which must be strictly managed and continuously improved. The main argument for having a methodology (e.g., an established process) is that it reduces unknown entities and thus limiting risk to producing the end product. It also simplifies project management by tightly scoping tasks thus simplifying estimations and projecting release dates well in advance. Couple of notable methodologies are flavors of Agile and Six Sigma, where the later originally developed by Motorola for manufacturing and has been retrofitted to software development with some success. The methodology selection process must analyze corporate culture, mid to long term objectives, industry trends, available skill sets and tools support, as well as other relevant parameters and constraints.
Any selected methodology must accommodate the 6 key process elements:
- Analyze
- Architect
- Design
- Develop
- Deploy
- Test
Other supplemental elements, such as code review, design approval, TDD (test module development must precede target development), refactor, etc. are highly recommended and raise general product quality. Not all of the selected process elements will be necessary for a given iteration, but, should be in place and analyzed for relevancy at each iteration. Development cycle iteration length should be moderately scoped to raise manageability and lower risk.
Implementation of a methodology must be scoped in a limited fashion to weed out potential risks and stumbling blocks as well as to tune the process to corporate culture and stated objectives. Once widely in place, the methodology must be monitored and analyzed regularly (complete the feedback loop) for continuous improvement.
Your A team without a fitting toolbox is on queue to become someone else’s team. The final leg of the team building strategy is selecting the building blocks and tools, most appropriate for the organization based on corporate culture, available skill sets, stated objectives, business model, and availability of the tools and platforms as well as reliability of respective vendors. Currently the two main competing platforms are .Net and Java, each with pros and cons. Selecting a development platform is only the beginning, a complement of tools must be built or licensed to support in-house development effort. Tools for configuration management, project management, various user interface components, bug tracking, etc. are commonly used supplementals and generally raise development efficiency. However, tools must be used cautiously and must be reviewed regularly for best-fit analysis, mainly because development aid tools such as CodeGen and CSLA may facilitate ease of use and abuse alike.
Development guidelines must be in place as well to fit the development platform, toolsets, and corporate objectives. Having the guidelines in place is not enough, it must be closely accompanied by enforcement mechanism, otherwise the guidelines run the risk of being ignored. A commonly used argument against following guidelines is that it raises development timelines. The argument may only be tactically valid but weighs in strongly against tight deadlines. However, the cost of not following standards is distributed across SDLC iterations and the old adage, “An ounce of prevention is worth a pound of cure” applies.
Select your team, process, and tools actively and as an organization or they will be implemented in some fashion by individual members which may not necessarily align with broader corporate objectives, raising potentially hard to detect costs.