Words on software and web development


Posts Tagged ‘methodologies’

Software strategies & tactics

There has been a lot of hoopla over the years regarding various software development methodologies. Personally, I’ve found that many of them distract from the real issues in software development. The only one that I’ve found appealing is Scrum, which is far more lightweight than most of the more traditional methods.

I find one thing missing from Scrum, however. Like most methodologies, it focuses on the strategic aspects of software development: what are we going to do, what are the steps we can break it into, how can we track our progress through those steps. It does not deal with tactics: how should code be organized, how should code be written, how should code be reviewed (if at all).

Advocates of various methodologies and certification models such as CMM (Capabilities Maturity Model) are probably jumping up and down and screaming, “But our approach WORKS!!!”

And I agree with them. All of the methodologies that have survived do so because they work. However, I’m more concerned with WHY they work than WHETHER they work at all.

Good software development aims at a balance between creative drive and consideration of consequences. There are many bright young engineers who can write code that works and find creative and well thought-out solutions to difficult problems. However, in my experience there is a widespread lack of considering the consequences of code changes or rewrites. Finding a better balance, where “better” means that the quality of code produced is superior, more maintainable, less bug-ridden, and better fits the requirements, involves a different approach.

This is what I like to call “delta-driven coding.” Anyone who spends a good deal of their time managing large chunks of other people’s code through merges will relate to this idea. Creating new code is also introducing a delta, or change.

And this is where we get back to tactics. Most methodologies are successful for a number of reasons, but one prominent (and slightly embarrassing) reason is this: they produce better code simply because they slow things down. In other words, most methodologies produce better software for the same reason that reduced speed limits are claimed to save lives: when people drive slower, they think more about where they are going and have time to react intelligently (if sober).

If we recognize the importance of delta or change, we can focus on the aspects of lightweight methodologies that encourage us to consider the impact of every change. This is the key to effective delta-driven software development.