In this day of being adaptable and agile, should we really spend time to document everything? Sure we need some documentation done but heck — it seems like I’m creating work for myself sometimes. Is there a fine line on what goes into configuration management and how strict of a practice we keep? -jd
Jon Quiqley: I think there should be, and I think there probably is. If you are in a company who is building Website applications, and you’re all self-contained and you know where the source code is at and it’s only in one place or two places, then maybe the risks associated with that make you inclined to take one approach that might be a little streamlined. The same is true with Agile; if you’re building something that has no potential for harm and there’re not many downstream consequences in terms of build, then you might strip away some of it. But the thing is this, it adds time but if you don’t do it, it’s probably going to add a lot more.
I will share a little story that’s a little embarrassing but, fortunately, it was 25 years ago, so I learned from it and moved on. When I was first out of school, a job at an industrial applications, I was building or designing 8051 embedded type control systems. I’m writing the software, I build a little bit, and it works, and I build a little bit more, and it works. They get a little complacent because I think I’m the deal because everything I build works fine. Then I sit down and I write, write, write, write, write, write, write and build, build, build, build, build, and compile it and I compile it with no errors. Now all along, I had not changed the source file name. I build a lot, I compile it, I burn it into the target integrated circuit, and I put it into the system, and the things that were working no longer work. In fact, nothing works; not what I added, nor what was there that used to function. I think to myself, oh man, I’m in trouble. Because my source code, I kept no traceability on what rev was attached to what. I didn’t bump the revision; I just kept on writing, and the compile was the same way. The only thing I had that worked was in an integrated circuit in another one of the prototype systems. I had to take the IC out of that system, put it into a reader and the hex code out of it and turn that into the assembly language.
That was a lot of work; a lot of unnecessary work. Why? Because I chose not to keep an iteration that I knew worked separated from an iteration that I was building in terms of source code and in terms of a compiled version. In fact, I got very lucky in that I didn’t just choose to overwrite the existing memory location of that IC with this new compiled version that gave me a good compile but didn’t do anything. That’s an example of a CM failure, and I will attribute it to my youth.
Jon is next week’s Podcast guest and this is his 2nd time on the Business901 podcast. The first time can be found here Discussing Project Methods.
About: Jon M. Quigley PMP CTFL is a principal and founding member of Value Transformation, a product development training and cost improvement organization established in 2009. He has nearly twenty five years of product development experience, ranging from embedded hardware and software through verification and project management.
Lean Sales and Marketing: Learn about using CAP-Do