agilenutshell

Test Driven Development promotes the idea of understanding what you are trying to build before you start building it, according to Walter Capitani, product manager for Klocwork at Rogue Wave. “It exposes weaknesses in requirements, in the architecture, and even in your test infrastructure before you start trying to build something. The counterpoint to that is you start building something and then realize you can’t properly test it. Then you put yourself in a situation where you are going to end up releasing something that was never properly tested,” he said. SD Times, August 2, 2017, Test Driven Development is alive and well.

I called it “code and go.” Someone asked if the software could do “X” and I’d say sure, and I’d go change the live software. There were a bunch of us programmers all doing this. Often we’d change the same software two or more different ways. When this happened we then got together and sorted out what would work for everyone. Sometimes someone wouldn’t like a change and we’d get people together to find a compromise. All this was about making changes to a software system used by many people to accomplish their daily jobs.

Eventually, we were told that this was too unorganized. It caused too many problems. Someone at the HQ directed that we use a lifecycle management technique where we would plan all our changes in advance, get agreement from everyone and then go make the changes. Each step of the process would ensure that such things as the requirements were well defined, the design and architecture accounted for everything important (e.g., usability, security, performance, resource optimization etc.), the coding was well documented, maintainable and error free and then an independent quality group would test to confirm that we had done everything we said we had done and we had done it error free. It was to be software development Nirvana. Well, it didn’t work out that way.

Too much of our methodology was based on what we were sure must be the best way. For example, if we work out all the requirements in advance then we’d never have requirements issues again! Nope. The ability to truly know the full requirements at the beginning, especially in a changing world and especially because we inevitably suffered from 2nd order ignorance and could only really learn by doing, the requirements weren’t fully defined until the last line of code was written and the customer had seen and used the program.

See How To Avoid Second Order Ignorance

The same was true of all the distinct phases. They sounded good in theory, but the ability to attain the stated goal of the phase was limited. The rest is history and we now have approaches such as agile and DevOps, which themselves continue to evolve.

But compare with The One Perfect Project Management Methodology

The test-driven development article above reminded me of all this. TDD sounds good, but because it sounds good doesn’t mean it works out the way the advocates say it will. I’ve done a bit of TDD and while it changed — for the good — how I look at testing, I’ll never again try to design and develop a suite of tests before I start coding. However, I do find myself often coding a few key tests in advance.

The point to all this is that it is useful to understand and try out various techniques. However, just because it sounds logical that some technique should result in some quality attribute (e.g. improved requirements) it doesn’t mean that it will, or that the benefits are worth the process involved. We can often only know by trying something out, such as in a pilot project or skunkworks. Only then would I recommend spreading a technique organization wide.

Do you know why your methodology works or are you just following a process on faith or because management requires it?