After 20+ years practice writing software, I’ve gotten reasonably good at it. Rather than follow a published software methodology, I’ve collected a set of techniques that can be applied informally, either alone or in teams, which I use when I need them. That said, I don’t just sit down at the keyboard and hack code either. 

Why not follow a published software methodology like XP, Scrum, etc? Over 25 years, I’ve seen methodologies come and go. By the time a team is trained on one, the fashion has changed, and so has the team. Like clothing fashions, each new methodology is a reaction to perceived weaknesses in those that came (just) before. Like fashion, a gaggle of evangelizing consultants earns big bucks hawking the latest styles. If you thought your geekiness protected you from fashion, reconsider!

Development methodology is also distressingly like religion. A prophet of the methodology claims it works miracles; claims he’s seen the miracle. Adherents to the methodology also sometimes have witnessed miracles. But most followers do so blindly. They have faith, in the prophet and the method, whether they’ve seen the miracle or not. I see a lot of emphasis on the methodology du jour, without a lot of thought about how that methodology improves quality.

Within each popular methodology are techniques that followers are expected to embrace. These techniques range from simple mantras of thought to vastly complex notations and meta-notations, and the expensive software and consultants they rode in on. Since I find myself on a new team for practically every project, I value simple techniques. They’re quick to teach and to learn, and it’s easier to tell that you’re using them successfully.

Because I wish there was an organized body of simple techniques to improve practice, I have begun setting down in simple language the techniques I’ve found most helpful. Writing them down has also helped me hold them clearly in mind. I’ll eventually link them to my web page here.

In a world of perfect practice, the waterfall development model represents the least cost. Requirements analysis perfectly captures user needs. The design is fully and correctly specified from complete requirements. The code flawlessly implements the design. Tests are run once but no defects are found in the perfect code. No changes are required. 

Some engineers are nonplussed that this model doesn’t work in the real world. The weakness in the waterfall model is that it assumes every step goes perfectly. Perfection is a hard goal for methodology, and for human practitioners. This doesn’t make perfection an unworthy goal, just a hard one. 

In the real world, knowledge of user needs can be imperfect. The many small iterations of the spiral model and XP provide prompt user feedback that improves understanding of user needs. If the design is imperfectly specified or imperfectly coded, these models provide feedback on the design that locates missing issues.  

Feedback about missing user needs and design issues ought also to inform developers that their practice and their methods want improvement. Some developers find this kind of feedback tiresome. They see spiral model-based methodologies as an alternative to doing a good job at needs capture, design, and coding, when really they are just a crutch to keep the project from toppling over after poor practice. 

A balanced, high quality software development methodology includes excellent practical techniques for initial capture of user needs, design, coding, and testing. It gives feedback to discover missing requirements or design issues. And it deliberately improves practice with the goal of reducing repetition of steps. Traditional methodologies attempt to maximize initial capture, but fell down when capture or implementation is imperfect. Modern methods are big on feedback, though not necessarily in a balanced form. But they don’t improve initial capture, and they are uneven on improving practice, mostly by being unconscious of it. Both the techniques and the feedback are important. Either without the other is like a bicycle with a broken wheel.