First, go read this.
Done? OK. For me, the choice quote:
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.Building software is an expensive business and there are always people trying to sell the latest and greatest improvements. The purported improvement is sometimes a product (a new IDE or language) and sometimes a process (XP, Agile, etc.). There is always a certain segment of the developer community that scrambles after anything that is new and shiny and with the advent of the web the frenzy of fandom can create more buzz than is deserved.
In an attempt to be "with it" the new improvement is tossed around as proof of how up-to-date one is. Previous approaches are dismissed and people who use them are dinosaurs.
Regardless, as the blog author points out (like I sort of did in my last post) software development at its root is fairly basic. In this case "Requirements, Design, Code and Test."
A book that influenced me strongly was The Pragmatic Programmer and its approach of "tracer bullet" development. The idea of roughing out a whole system with stubs where real code would eventually go was appealing. You could quickly get a rough idea of how the whole thing would hang together and could immediately see what pieces would be more effort than others. Not surprisingly the authors of that book became influential in the whole Agile movement.
The marketing and buzz that sprang up around Agile now means that the term is tossed around without much care as to what it means in practice, as long as you sign up for the seminar or pay to be certified as an Agile coach. All that management hopes for is that they can start to get more software faster than they did before. Unfortunately for them all of this glosses over many other items of importance like the huge differences between the abilities of individual developers.
I think that there is room for discussion on craft vs. engineering in software development. People who write code for a living, day in and day out, are close to the workings of the technology and have an intuitive grasp of what they are doing. Attempting to impose engineering rigor on the process gives the illusion of control with boxes and lines and probably some kind of metrics. At the end of the day the develop has to know what is supposed to be built and have a clear idea how they are going to do it. The rubber hits the road when the developer hits the keyboard.
I am not sure if there will be some kind of a backlash an a "back to basics" push anytime soon but I for one start to tire of the relentless onslaught of new approaches that do not offer significant benefit over known and proven approaches. There is an awful lot of code out there that would be considered obsolete by the current cutting-edge developers that nevertheless is important and valuable to businesses.
Being techgnostic means keeping all of this in mind before embarking down the path of new software development. What you already have might basically do what you need (Pareto principle) or what you need might be a one-off fix that does not warrant a full blown process. Step back, take a deep breath and ask yourself what you are trying to accomplish and produce just enough to make it work, getting something out sooner rather than later.
