Once upon a time, there was no source control, bug tracking, documented features, etc, and the new processes that introduced these things improved productivity and end results. These are good processes. Unfortunately, the pendulum has now reached the other side and development is over-processed. The new processes seem to have stemmed from trying to make poor programmers better. As a company sees too many defects in their product and too many disappointed customers, they look to root cause a bug and solve any future occurrence via process. This fix-by-process attitude is the root cause of over-processing the software development cycle. The problem is not the process but with the people. New processes that force everyone to follow a “proper” programming, testing, and automation paradigm, just slows down development and frustrates the good people in your organization. Not every feature, change, and bug fix fits into a prescribed step-by-step process. It just doesn’t. The end result are engineers bypassing processes, attending unnecessary meetings, lazily (and inaccurately) filling out fields and forms that are required, scoping out features that will never make it into a product, and so on. So how do you produce better software with fewer bugs and on time? You definitely don’t create more process. Instead, you start with the people, fully enabling your best engineers and developing processes around them (not the worst engineers), understanding the product and *not* falling into the feature bloat trap, pushing for full attention-detailed testing, defining and vetting interfaces (which is where most bugs occur), requiring modular and preferably object-oriented coding, and minimizing meetings and interruptions to be as productive as possible. This is how you deliver a great product.
If it sounds that I am against process, I am not. I believe in a lightweight process as I have seen it succeed and I have seen products using heavyweight processes fail miserably. I have had the advantage of being able to define just about the entire software process for my product and was able to tweak this process every release. I have seen what works and what doesn’t. I intend this blog to be the (mostly) non-technical story of what I have learned over the years about the software development life-cycle, and I want to share what I have learned.
I am extremely aware that I have worked only at a handful of companies and within each, a handful of projects. It is not enough data points to make universal claims about all software. While I may state things as universal, I know they are not. You may find processes that work for your team that I adamantly advise against, and vice versa. I’m not here to push an agenda or tell you what is right. I’m here to tell a story and share opinions. Enjoy!