As an engineering student I was impressed by the intricate harmony of development processes. It was probably the same part of me that loved the uniformity and audacity that is xml.
These days I use JSON 100 times more often than xml. I’ve similarly fallen out of love with process. But there’s still a grudging respect there. Like an old lover that done you wrong, but is a sort of evil superhero so you’ve got to respect.
Now I’m a manager, and many developers dismiss my thoughts on process. But there’s good process and there’s bad process. The trick is telling them apart.
I’ve been trying to foster one good process: The 5 Whys. Continue reading Brakes That Don’t Slow You Down
Agile: the Good Parts (according to Bertrand Meyer):
developing in short iterations of two to six weeks … has profoundly transformed the software industry for the better.
absolutely no one, regardless of rank, is allowed to add anything during [an] iteration.
And now, some bad bits of Agile:
the general rejection of what’s derisively called “big upfront anything.” … The agile world has this phobia of not producing anything that’s not deliverable to the customer. … the idea that it’s bad to spend an appropriate time at the beginning of the project to clarify the overall requirements and design is nonsense. You do need at some point to focus on the deliverables; but until then you should take all the time necessary to address the big issues of specifications and design. I’ve seen projects fail miserably for blindly applying the Agile catechism: we’re Agile, we don’t need to stop and think, we just go ahead and code! Not surprisingly, what they code is junk and they have to redo it….
Bertrand Meyer in the article “Object Lessons” by Leah Hoffmann,
March 2015 issue of Communications of the ACM, pp. 95