Man, it seems that every few years there is a new software development methodology that comes out and while not purported as the 2nd coming, it certainly has all of the fanfare of the latest and greatest.
Let’s see there has been CMMI, TDD, Agile, Scrum, Lean, Waterfall, Continuous Integration, Spiral, Extreme Programming, RAD, MDD, YAGNI, Cowboy Programming, and the list goes on. I would like to add to the list an oldie but a goodie: Brute Force Development or BFD.
I would suggest that BFD is the most widely practiced software development methodology in the world. In fact, I would claim that the majority of organizations and people use this methodology daily and have been since the inception of software development.
How do I know this? In the real world of software development, where the size and complexity of even the smallest projects (e.g. >5000 lines of code) exceed the allocated budget and timeline, almost everyone resorts to brute force development in the end. Why? Because, we have to. How else can we do it? When was the last time, as a professional programmer, that you actually finished your project/product on time and on budget? Did you do it working 40 hours per week? Honestly?
Typically we start out with the best intentions, but as the schedule starts to slip and the budget is disappearing at the rate that a 426 Hemi goes through a tank of gas, we drop in BFD mode. We try and do the impossible. Extra hours are burnt, features are slashed, quality goes out the window, and we brute force our way to meet the impossible schedule.
Now, I am not complaining. This is just an observation having worked in many different shops, large and small, including my own start-up. We end up with BFD in the end.
Heck even the guru himself (who I have nothing but respect for), in his own post called, "Building a Fort – Lessons in Software Estimation" made some pretty interesting slip ups. My favorite was the, “I dropped a little piece of my laser level down the side of one of the footing holes, between the concrete form and the dirt, after I'd poured the concrete.” Oh Steve, think of all the things we have dropped in the software!
I will go out on a limb by saying I have yet to see any evidence that we, as software architects, developers, estimators, etc., are actually getting any better at this. I have been doing this for 18 years professionally and maybe I am dreaming, but it seemed simpler years ago. Not just that the requirements were simpler, but even from a technology standpoint. What I mean is that software vendors that produce tools, programming languages and applications have grown (seemingly) exponentially during this time frame as it seems any solution (and the tooling, languages, and apps) I am involved in has way more moving parts. A lot of these moving parts are new and unforeseen issues crop up well into the development cycle where one vendors library interfaces don’t seem to match what the documentation says, for example. And then we brute force it – to make it work.
Part of this is tongue in cheek as there is another meaning to BFD than can be applied to programming methodologies. You can get a hint by looking at the blog category this was filed under. I sincerely don’t mean any disrespect to the authors and believers of these software development methodologies, but sometimes the “marketing messages” can be a little much and even downright embarrassing. For example, try explaining to your significant other what Agile and Scrum mean. What do you think the “business folks” are thinking when you explain it to them? Do they even care? I would hazard a guess that all they care about is how much is it going to cost and when can we start using the software. Btw, they are also thinking, it better do what I want it to do for this amount of money... or else...
So the moment that things don’t go as planned, BFD kicks in. Whether you know it or not.
In 1994, before most of these methodologies and marketing names came into effect, I had the good fortune of taking a 2 year post grad course in Software Engineering Management at the
University of Calgary in Alberta, Canada. It was taught by Motorola University and one of the instructors, with 30 years experience, had some awesome stories on how “yer doin it wrong.” The funny thing was, while we learned a great deal about software engineering (that’s the last time I write 17 exams in 2 years!), what we learned most was common sense and communication. In other words, how to tell your customer (ahem, the one paying your rate, salary, contract, or whatever) that we can’t write 100,000 lines of code in 2 weeks. The real methodology here folks is just called common sense.
I don’t think much has changed since then as we are always fighting that battle. Developing software for any decent sized project (>5,000 lines of code) is really, really hard, maximally labor intensive and fraught with… well, you name it.
I can hear the Agile folks saying that our methodology is the one that mitigates this risk. While that may be partially true, how do you answer the top two questions asked by the customer: how long will it take? And how much will that cost? And our requirements list is just that, a one pager with bulleted high level fatures items and some of the bulleted items have two words explaining the requirement. Oh yeah and at fixed price. Ready to sign up? In the end, in order to make that deadline or not burn through your fixed cost, it's BFD man. That’s the reality. And btw, could you not have come up with a better name. I mean did you not know that Agile is Dead?
So what’s my point? Well, aside from having some fun with the BFD acronym, as with most things, there is some truism there for sure. We have all done it, yes? I am sure that anyone that has written code for any length of time has done BFD. Which makes my newly minted, TLA marketing buzzword an instant leader in the world of software development methodologies!
All kidding aside, maybe it is time to step back and look at some of the basics for any software development project. The very first I would think is answering the two most basic questions of any software development project – how long and how much $’s. Do you have a predictable and repeatable way of doing that? How accurate is it? If you don’t, then you are likely to be doing BFD even before you write a single line of code and therefore none of those fancy software development methodologies won’t help you one bit. Know what I mean?
Remember, keep the rubber side down!