More Reasons Why Software is Hard
More Reasons Why Software is Hard
Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
If you‘ve spent any amount of time cooking, you realize that being fastidious at following a recipe does not a good cook make. That said, just slinging hash out of a six shooter and squeezing out cheap flavor sources (e.g. lots of butter, sugar, or worse, things like MSG) is not the answer either. One of the common anitpatterns in cooking is the person who gets flustered easily and hence slows down the whole meal. The result is often all dishes are cold and lifeless by the time it‘s all served. Do metaphors give us anything? Sometimes. I think a few of these are worth running down..
Getting to the Window
In Programming, the timer/coordination free ‘myopic focus‘ is the norm. I almost never come across devs who are really good at staying laser focused on bringing their food to the window. The show Hell‘s Kitchen is in like season 12. I haven‘t watched all of them, but one of the great things about that show is the same scenes occur over and over again, despite the fact that the faces are all different. (This is one of the great things about reality television in general, it can climb up the Eleanor Roosevelt tree and end up being about ideas rather than just people.) The first couple services are almost always painful lessons in the fact that a restaurant goes down hard when it can't get anything to the window. On Chopped, this also happens with regularity. But there is a special case on Chopped that always gets me. I love when people do things like try to make rice and don't start it until like 5m in, and then they say something like 'I know it's not enough time but I am hoping it ends up getting cooked.' That's kind of the equivalent of 'I know 2+2 = 4 but this one time, I was hoping someone would make it come out to 5' [thank you Fyodor Dostoevsky]. We do that kind of stuff all the time in development. Piece needs to be in the build on friday, Thursday enough remains to take it to Monday. When questioned, dev says something like ‘was still hoping to get it done.‘
Ready for a surprise though? I don‘t really blame the devs. Our process, which is all puffed up with itself, doesn‘t take this stuff into account at all And tools are even sillier. The state of the art is a list of tasks, with no concept of time at all. Kanban‘s concept of time? BYOT. Just had my millionth experience of having a group of ‘managers‘ ask for estimates, then when I supplied stories (not tasks) with story points on them, was asked ‘how many man hours per point?‘ Really? You‘re really going to ask me that? Have we not discussed this ad nauseum? Nevermind that, could you not be bothered to lookup story point? I suggested we take a first part of the piece and do it and get an idea of velocity. They opted, instead, for just throwing down something like 1pt=7h. And we are supposedly the vanguard of the new economy.
Scrum is really no better. Frankly, I think time management is better in Kanban, even though it‘s nonexistent, because something non-existent is better than something fake. Iterations, for all their machinations, are ultimately pretty meaningless and way too much work for what they provide, which is a sense of security to the noncoding horde. They are like a train schedule. ‘Oh, look, my piece will be here a week from Friday!‘ [Of course, you are muttering to yourself ‘don‘t get all dressed up until you hear it coming…‘] In Kanban, you are always seeing the funnel that is leading you to the release, and you can manage it a little bit better. So let me modify my prior statement: Kanban is better if your software project relies on constant bartering and malleability. If it doesn‘t, you must be working on the nth implementation of some boring simulation, in which case, you probably can tick off your iteration plans without spending a developer seat on constantly publishing utterly meaningless updates (percent completes or equivalents).
The future of programming is swarms. This is one of the reason that open source has more life to it than most projects. There is just no replacement for being able to keep energy and momentum high and using that to keep a steady flow going. The direction of that flow is secondary and in most operations, there is absolute confusion on this point. They don‘t mind their flow and they constantly convince themselves of the most fundamental illusion in software: ‘if I had done a better job of organizing this I would have gotten the desired result.‘
Get the pieces to the window, and hope the people who are deciding what should be in the window are decent.
One last thought on this thread. One of my organizational heroes is the late great Bill Walsh. I saw him just sitting eating fried chicken in a restaurant in Palo Alto in 2000. I usually have zero desire to say anything to someone famous, but I was dying to talk to him (but didn‘t). One of the things he used to do is go to the game with the first 25 plays set. The reasoning was that in the beginning of the game there is too much potential for making crazy decisions and losing sight of the plan. I have been thinking a lot lately about how plan less our process is. Taking a thing and writing the requirement up as a story, then breaking down its tasks, does not a plan make, people! A plan is something completely different.
Published at DZone with permission of Rob Williams , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.