Your favourite methodology is eXtremely gay

A good software process will not save you from bad programmers: the best methodology is to just hire the smartest people you can find and get the hell out of their way.

When programming, you can never have too many comments. No, wait… when programming, you can never have too many jelly donuts. I always get those confused. The former is an example of a coding standard, which can be part of a programming methodology. The latter is an example of a software development process. In this entry we'll discuss the difference between a software development process and a methodology, and why neither really matters.

Software Process and Methodology
As mentioned previously, software engineering is the name given to the branch of computer science whose research focus is the application of engineering rigour to the problem of building large, complex software systems on time and on budget. A significant amount of this research effort has involved attempting to develop a formal process (the engineering rigour part of the definition) that can ensure repeated success in developing software.

A software process is the set of steps taken in the development of a software product, where each step has a set of deliverables (usually in the form of documents) that are signed-off by an authority. This is known as visibility, and is considered an important aspect of being more rigorous. There are a lot of benefits to being visible, including automatic ass-covering (“but you agreed to this specification…”) and having something to give the new co-op student to read for the first few days when he or she arrives for work and you have nothing prepared for them to do yet. The waterfall model of the software development life cycle (covered in an earlier post) is an example of a software process.

A software development methodology fills in the details of how each step in the software process should be done: what are the specific deliverables - and their format - of each step in the process; how should the system be decomposed into modules; do we program in pairs or alone; do we utilize code reviews or unit test, etc.

A methodology is about taking a disciplined approach, whether it is to making coffee, investing in the stock market, or writing software. In the case of an investment methodology (following a particular method because you believe it is philosophically superior to other practices), the resulting discipline ensures that you will likely make money even if the majority of your stock picks don’t pan out. How? By cutting your losses early and letting your winners ride. Likewise, a good software methodology will serve to help minimize your losses by, for example, catching bugs as early in the process as possible, or by achieving a working system that is easy to change.

To further elaborate on these concepts, let us revisit the stages of the software development life-cycle.

Requirements
Stroustrup suggests that knowing what it is you are building is the crucial first step. However, if you have a target or pre-existing user community that will provide feedback (quite vocally, I may add), is that even possible? I can’t recall any significant software project that I have worked on where it was known ahead of time exactly what the artifact would ultimately become. Unlike many programmers, I don’t see this as a curse. Rather, I see this as one of the most compelling reasons to build software rather than less malleable consumer products. I think it is tremendously exciting to work within a medium that is so fluid. While I can see that you wouldn’t want to start construction on a condominium tower without first knowing what it was you are trying to build, there is no good reason to assume that such certainty is possible or even necessary with software.

The grouchy programmer’s insistence on a clear, complete requirements specification before design and coding begins is annoying. It is a fact of life that the requirements will change, so why insist that the spec exists beforehand? Embrace the chaos: come on in, the turbulence is fine! And if you can’t, might I suggest zoloft or effexor as an excellent means of combating that anxiety.

Design
If you don’t have the design right you might as well go home. Mistakes in any other phase can be corrected after the fact with relative ease compared to the pain of redesign. How do you learn good design? Same as how we humans learn anything: Through imitation of others who are good at it, and by doing it and learning from your mistakes.

Implementation
Alec Baldwin in Glengarry Glen Ross said it best: "A-B-C. Always Be Coding." At least I think that's what he says. I wasn't really paying attention.

Testing
In any online business, first to the post is a crucial advantage. If you take the time to follow a traditional software process, you risk failure for the entire enterprise. At abebooks.com, we developed our own software process (speed programming (tm)) to cut back on the time it took to ship new versions of the website. Its defining feature: user testing meant “the users tested the software for us.” Everything was in beta, all the time. Eliminating an entire phase of the process was certainly a massive time-saver.

With Alibris nipping at our heels (with their bags of American venture capital and glossy ad campaign), we didn’t have time for code reviews and regression testing. But fuck it if we were going to let those assholes beat us. We were there first and worked feverishly to maintain the lead.

Don't try this at home: skimping on test is always a bad idea. What saved our ass was that we were leaner, meaner, and smarter than the competition. Our agility (the ability to quickly recover from boneheaded mistakes) and complete control over the deployment process enabled us to survive. We were good, fast, and cheap. Over at Alibris, it was apparently good, fast, or cheap: pick any two. Or maybe it was gas, grass, or ass: nobody rides for free.

Maintenance
Alas, the relentless pressure to constantly be shipping will take its toll. The term Internet years is really about their effects on your body: one year of development in this environment will age you by five years compared to the six month release cycle employed by shrinkwrap and custom retailers. Inevitably bugs in the web app will arise due to unforeseen spaghetti effects and the compressed development cycle. At this point, it is not uncommon for management to ask for a post-mortem analysis of why that innocuous change resulted in 18 hours of downtime. At my previous employer this became unnecessary once they adopted what became known as Russ's Rule: it is always the DBA's fault. It became such a time saver in the whole software life-cycle that it was officially codified in their project workflow template.

The Problem
Software engineering is unique amongst engineering disciplines in that adherence to accepted methods and a rigorous, visible process does not guarantee success. We have yet to discover any software process and methodology that ensures repeatable results when it comes to developing large complex systems in an efficient, cost effective manner. But in my experience, it's not the methodology or process that is to blame if a software system fails to meet requirements. Rather, the blame lies squarely at the feet of the software engineers who were unable to tackle the complexity of the system under development.

Conversely, the best software engineers are able to repeat their previous success, regardless of the task laid before him or her, and regardless of the software development process or methodology utilized.

For example, building a scalable, highly available web application in a modern programming language like Java is subtly complex. The programmers need to have a strong grasp of programming concepts such as: multi-threaded programming and thread synchronization; caching; database connection pooling; database transactions; and, data structure and algorithmic analysis, to name but a few of the things that immediately spring to mind. The complexity of the underlying database management system alone can lead to project failure if someone on the team lacks the requisite knowledge to manage the system as the size of the database grows. These complexities have nothing to do with software process or methodology and everything to do with the intelligence, experience, and judgement of the people on the team.

This may be our industry's dirty little secret: programmers are not interchangeable commodities.

What to do?

First, understand that the weakest link metaphor does not apply to software development project teams. The team is much stronger than its weakest member. In fact, it is quite the opposite: a software team is only as good as its strongest member. Experience, judgement, and talent do not magically coalesce from the interaction of the individuals. Good software is not an emergent property of decentralized collaboration between average programmers. The project will succeed if and only if the complexity of the underlying system is within the grasp of at least one member of the team. The software process and methodology is irrelevant. But they remain the opiate of the management. Your favourite methodology won’t save you from bad programming, but it will give you something comforting to cling to while the ship is sinking.