Peter Welch’s post, Programming Sucks, has been making the rounds and I feel compelled to comment on it.
This article embodies the distinction between amateur hour and professionalism. Between those who can create good abstractions and those who cannot. Between someone who understands how to separate concerns and someone who does not.
I fell in love in the first section where Peter creates an analogy about walking into a new team that’s building a suspension bridge but no one knows how to build a suspension bridge and there’s one guy who works only with wood and you don’t even have experience building bridges. It does a fantastic job of painting the characters that we all are. But as I read further I started to get a bad taste in my mouth. Something was not quite right.
The article goes on and on without coming to a conclusion or addressing a problem or solution. It is a self-described rant but that is only a thin veil. We start out with the premise “programming is just as difficult as physical labor” but then quickly move on to the main theme of “beautiful code cannot survive in the wild”; as soon as the business gets its mitts on your code it will fall apart and become part of the big-ball-o-mud that everything else is. This is fear of the code that you and your team just wrote. This has a name, it’s called Programming By Coincidence. This is the inability to reason about your code and create strong concepts within your application. Business requirements will get added on and changed at the last minute. That’s the nature of the game. The ability to adapt the code accordingly is what we get paid to do. If we’re designing our applications properly we can put off decisions as long as possible and afford ourselves more decisions down the road. To throw our hands up in the air and admit defeat is simply throwing a temper tantrum because, gosh darn it, it’s hard.
All that, in and of itself, would not be bad. What really got me was how widely this was circulated on social networks with comments like “so true!” by people who get paid to write software and call themselves “engineers”. How do we reach this level of despair? Some days can be brutal, I know. You have to deal with Product Owners getting antsy about deadlines. You have to deal with that one dude who doesn’t care because, like, man, it works or whatever. But this is our responsibility. It cannot be blamed on management. The company you work for _implicitly_ expects you to do the right thing. Oh sure, they’ll say they’re fine with cutting corners to get that feature out the door this iteration but they don’t understand what they’re asking. They aren’t going to understand why, after a few months of doing this, the next similar feature they ask for is going to take 2 weeks to build instead of half a day. This is the same way you wouldn’t understand why the next brake job on your car costs 10 times as much and takes much longer because this time you said, “well, instead of waiting for the parts, couldn’t you just, I don’t know, weld something into place so we can ship it?” Imagine your mechanic agreeing to that. Yeah, he may have you happy today and for the next several thousand miles. But when you go in next time and hear the estimate you’re going to shout, “why would you have done that?!” His reply of “because you said so” is not going to cut it.
And, yes, you will need to take on some debt from time to time to get the release out the door. But pay it off in the next iteration or two. Don’t wait for your manager or Product Owner to give you the go ahead. They will not be able to successfully balance the cost of this debt vs the cost of a yet-to-be-implemented feature that has real dollar value. At least not until it’s too late. This is your job, not theirs.
Here’s some antidote for you: Check out this awesome keynote by Uncle Bob on architecture and tell me it doesn’t inspire you to take your software to the next level. If that doesn’t do it here’s a great talk by Jim Weirich about how to separate concerns and decouple your applications. We don’t all have the good fortune to work with someone who inspires us, which seems to be the case with Welch. You will not regret the two hours you spend watching these videos instead of Game of Thrones (or whatever you kids are into these days). Dozens of other talks could be listed but start there and, goddammit, do something about it. Don’t give in to entropy and incompetence. Push yourself, make yourself better at what you do. Teach others who are struggling with it. You can do it, friend.
