I may be getting old, but I don’t think I am out of touch. My sanity of being a software development professional seems to be tested daily by our industries predilection for Silver Bullets. The latest it seems is Scrumban. My wife can’t stop laughing when I say it to her.
I have not read the book, so I have no opinion on it. I have read some of the author’s blog material. Seriously, I mean no disrespect to Corey Ladas at all, but when I read the material, I can’t help to think that this is written by someone with a MBA. When I read this article, I think I get what he is saying, but I swear it is written in a different language than the software engineering world I live in.
Regardless of what marketing terms are used, the reality is that software development is always: understanding the requirements, creating a design, implementing the design, and testing the design and implementation to ensure it meets the requirements. Requirements, Design, Code and Test. Always have, always will, no matter what other fancy (marketing) words are used to describe it.
With respect to very large software projects, I understand the label Feature Crews, but to me, this is nothing more than classic functional decomposition at work, but with a new (fancy marketing) label.
Questions that the Agile, Scrum, Lean, give it a name, practitioners seem to never answer is the two most asked questions by people that pay for software development projects, which are, “how much is it going to cost and how long is it going to take?” It seems there is no best practice in any of these methodologies to answer these fundamental questions as these methodologies are focused on very limited scopes of the project as opposed to the entire project. And quite frankly, that is my main beef with these Silver Bullet’s, because as Fred Brooks postulated 23 years ago, there is no such thing as a Silver Bullet in software development. In my opinion and professional experience, he is right.
Software development is an incredibly complex, massively manual labor intensive effort, whose primary work product is lines of source code. For people that write code day in and day out, know this to be the truth. There is no hiding from it. We grind it out as we know how and love it. So when I am asked how much the software development project is going to cost and how long it is going to take, I apply a tried and trued approach to answer what is a very, very difficult question. This is why you see software estimation models like the Constructive Cost Model or CoCoMo for short. You can read the gory details of the model here. PDF alert! No surprise to see that counting lines of source code (or equivalent lines of source code) is the way to answer the tough question of how long and how much. Dr. Barry Boehm had it figured out years ago. When I took Software Engineering as a post graduate course at the
University of Calgary, this is what we were taught and has been consistent with what I have found in the field. So yes, I use CoCoMo to answer the ugly, gnarly questions. And there are several automated tools that implement CoCoMo’s model, even ones online.
So what has happened to our software development industry that we need to keep reinventing the wheel in the name of continuous improvement? I think it is indicative of anything that is really tough to do. Everyone is looking for an easy answer or the next big thing. But as most things in life, the answer is already figured out. You just need to look in the right place, listen to wisdom and apply some common sense. Congratulations, you just made pro software engineer!
What’s my point? My point is two fold. Our software development industry is being run by marketing people and has gone insane Ok, I half jest. I know over time the pendulum will swing back to the basic fundamentals of what software development really is. My other point is to the young aspiring software engineers. Kids, look at some of the real software engineering techniques that hold up to the test of time. These are the gems. This is what is real in our industry. CoCoMo is real, it works, and is based on facts and historical proof. If you were to only read one book on software engineering, read the as it embodies what is really happening in our software development world, regardless of when the book was written. There is a reason why Fred Brooks earned the Turing Award. Your assignment is to understand why.