Web development and process fads

In my time within the technology industry, and specifically in making web applications, there are interesting process trends that represent indicators about organizations without even needing to know the domain or industry the organizational business space a company inhabits.

 There are some tried and true elements to the software development lifecycle (SDLC); stuff that goes all the way back to before object-oriented design and programming existed. A lot of is easily garnered by sitting down with some computer science history books, looking at many thorough analyses of the efficiency and stability of solutions and the fundamental approaches different companies used.

Many large companies used groundbreaking approaches while others did not; thus, creating a great array many researchers writing these books might gather. At this time, I am only recalling from my memory of graduate school and will not do any quoting of statistics or anything like that. I do know that I am generalizing a lot in my statements, but the basic conceptualizations should remain accurate.

The biggest things that I recall about SDLC efficiencies, is that early design and early testing resulted in reducing the cost and time of development, improving overall product stability (reducing bugs), reducing final testing time, and more consistently lead to on time delivery of products. There are equations in software engineering specifically for the purpose of how much productivity you get out of the number of developers you have available to code. While it is true that more developers reduces the development time of a solution, past a certain number of them (as I recall), the reduction in time does not equal the relative cost of the developers. To that point, the particular number of developers where that equation was no longer equitable is lower than one might assume. This is sometimes called the developer to tester ratio, and while it makes lots of assumptions, (such as developers of equivalent productivity and skill, etc.), the tipping point where more developers costing more money or just flat-lining the productivity of a team is considerably less.

So past that idea, (but keeping it in mind), is that most of the SDLC processes today are meant to address the management of software development.

In the age of mobile and web development, we have many SDLC processes that try to mitigate the balance and cost effectiveness of that equation. Every company making software wants to do it as cheaply as possible. This is a given, because business if about profit, and if you are spending money on doing something and not selling it, you are not making any money.

The SDLC processes that came about because of the mobile and web development markets revolve around small teams and rapid change, because the basis for these technologies change abruptly and rapidly, imposing a demand on consumers of them to change with nearly the same speed.

This introduced extreme programming, agile, agile scrum, kanban, agile lean, and a movement away from waterfall, iterative, capability maturity model (CMM), etc. The funny thing is that in many of these cases, we have an SDLC process highly dependent on heavy communication, less business design documentation, more abstract specifications, and greater ability to navigate the path to delivery. The deficit to this is the heavy communication portion. If a team is not small enough, these methodologies require even more communication on top of the heavy communication, starting to make the design documentation and business requirements more necessary. If a team is also distributed (multiple locations), you have less independent team autonomy, less rapidity in process, and a need for heavier communication. All these approaches still highly depend on a situation-by-situation analysis.

In one case, a small portable team is quite capable of delivering a product or components of a product independently, but in many cases, you end up with many small teams trying to work cohesively. This falls apart or encounters issues with a need for increased communication. Therefore, in smaller team delivery SDLC processes, communication is the keystone.

The slower delivery SDLC processes major deficit is rapid change. They all suffer from the inability to quickly adjust and handle the needs of quickly changing technologies, fundamentally crippling them and the ability to compete with faster moving organizations. Better design and business specifications serve to mitigate a lack of communication quickly, since most other processes can leverage heavy documentation practices to supplement the need for lots of communication.

Web development favors faster moving processes, but created a culture of fad-based SDLC processes. Many software product companies struggle with the transition into the web space, because the same processes between creating software development in one approach does not apply to the other. The hardest part is then not trying to impose one process on the other, but to sit back and really look hard at the best way to manage the production of a software product in the current space.

If you are talking about years of time, say 1-3 years, you can slow your process way down and do things right. You create larger teams, increase documentation, and do thorough and thoughtful design, with comprehensive business requirements and specifications. If you are trying to make a complete software solution in months, meaning it is 100% complete in that period, the faster approaches are probably a better way to handle the management of that SDLC.

I think the web development industry has pushed the more faddish approaches to make web applications because many people enjoy the mobility in those processes as it gives a sense of freedom in the ability to change. The problem is when you are looking at sustaining those processes for long periods, especially over years. SDLC processes meant to handle the length of development should be a major consideration in the approaches an organization takes in considering the best way to go about implementation.

We rush to use SDLC approaches like agile because of good experiences with it, rather than really considering the best impact over time. There are many parts of agile that apply well to slower processes, but when building a larger product, or when considering different approaches, it is important for the people making those decisions to not just "go with it" for the purpose of being welcoming. Adopting a SDLC approach because the fad feels and sounds good is dangerous and not every process matches every company culture, nor the culture of your customers. I think every process is worth evaluating and considering, and maybe even taking the time to borrow concepts from each, developing a new process that fits right for your organization. I call the approach to adopting or changing your SDLC process through multiple-process evaluation "Radiant Election."

Radiant Election is not a SDLC process, but a way to pick a new one. It involves an educative process for decision makers, where they work with a consultant who guides and mediates the various components of these processes. After that, the decision makers discern which set of components will work best for what parts of their software development processes organizationally, and implement the training for the newly adopted SDLC process components. This modular approach allows for a highly customizable and optimized SDLC process designed to complement the existing infrastructure and practices that already exist within the organization.

While this is all a simplification, and these concepts tend to be harder than “picking a bunch of options from a list,” it really is not difficult to get an understanding of how the SDLC processes work, take the time to educate decision makers and stakeholders in the business, and guiding them on the advantages and disadvantages of each option. This is much like making any reasonable business decision.

I hope to one-day see a divergence from this fad-driven SDLC adoption, and more thoughtful process approaches that work better within existing profitable companies.