And, like many older teenagers, his sleep habits on weekends are not quite . . . habitual. A Saturday 3am steak craving has been known to happen. To his credit, I've never woken up to a fire alarm or any other emergency. But, I always know when he's had a craving. The kitchen is not quite as my wife and I left it the night before. The steak has been put away (in his stomach), but nothing else has.
As far as he is concerned, the process of cooking a steak is finished when the goal of eating a steak has been achieved. Every step to the right of the goal is unnecessary. Which is obviously not true. Processes have a lifecycle of their own, regardless of the goal(s) they are supporting. If he was cooking a steak for his significant other (which he has done), the process remains the same, even if the goal is different.
Every time I get on him about cleaning up after himself, he gives me this look. Every parent knows exactly what look I'm talking about. It's the "I'll do it because you'll punish me if I don't, but you haven't convinced me of why I should care" look. He's a hobbyist.
Compare this to what the chefs do on Hell's Kitchen. These cooks are not just professionals, they're consummate professionals. After a long day of challenges and a night of creating 5-star food while being yelled at in public, they are still cleaning their stations and washing the pots and pans. It doesn't matter how rough it got between them - at the end of the day (literally!), they work together to finish the process of preparing 5-star cuisine. The end of that process is to prepare for the next time the process is execute.
This separation of process from goal is equally true in every facet of our lives, and especially true in the development of software. The goal is obvious - a functioning application that our customers can use. The shortest path to that goal is:
- Make production server (if necessary, otherwise skip to next step)
- Edit code on production server
- service apache restart (or however you source in the edited code)
- Send email announcing new feature
This is called DIP, or "Developing In Production". It's what 99% of the world population thinks we do, including many stakeholders, most business analysts, and all users. Oh, and that one developer in the back who only works on ancient ASP4 or PHP3 apps. And, to a (very small) degree, this process works. The application does tend to work, to a large degree, most of the time. And, for hobbyists or businesses which can tolerate large amounts of downtime, this minimalist process could serve quite nicely.
For the rest of us . . . not so much.
DIP, as a process, leaves much (well, everything) to be desired. It is this-goal focused. We need to get this feature out. We need to fix this bug. The implicit understanding behind it is "And nothing else matters." There is no preparation made for the next execution of the process. The plate and utensils are just left on the table with the grease congealing. The pan is left on the cooling burner, a hard crust forming. Nobody puts away the seasonings and the sauce curdles overnight.
Tests aren't written, so nobody knows (or remembers) exactly how something is supposed to work. The environment setup isn't documented (or automated), so every server build is a one-off that takes days and is still never the same. There is no source control, so nobody knows why something was done. The ticketing system (if there is one) loses information, so nobody even knows what was done or when or for what purpose.
If the thing you did was the last time anyone would ever have to deal with that application, then none of this matters. But, what's the chance of that? In my 20 years of working in IT, that has never happened to me or anyone I have ever met or even in any of the stories they have told.
In short, every change you ever make to a system will have another change after it. The process of making that change isn't complete until you have cleaned up after yourself.
No comments:
Post a Comment