Code Quantity =/= Personal Awesomeness
“Look at all the code I wrote!”
If you hang around #CowboyDevelopers for any length of time, you’re sure to hear the above refrain. It is a bit of a catch-all phrase, but the situations you’re most likely to hear it involve
- 1. Bragging Rights: Code quantity as a proxy for capability. Or, to put it differently, “Mine is bigger than yours”.
- 2. Settling Arguments: After all, it’s a well known fact that the amount of code you write is directly proportional to how correct your implementation is .
- 3. Continuing With The Current Approach: Basically the Sunk Cost fallacy, the amount of code that was written by the #CowboyDeveloper is consider dispositive evidence that the current approach is correct.
The commonality to all of this are the implicit assumptions that
a) Writing code is hard.
b) Therefore, the more code you’ve written, the more hard work you’ve done.
a) Writing code is hard.
b) Therefore, the more code you’ve written, the more hard work you’ve done.
Yes it’s true — in absolute terms, writing code is hard.
That said, in the world of Software Engineering, writing code is not the long pole!
That said, in the world of Software Engineering, writing code is not the long pole!
Take the life-cycle of whatever is being built. Odds are that it goes something like this
Identify the problems
Identifying all the requirements associated with whatever you’re building, including who wants it, what they actually need, what they’ll be satisfied with, timeframes, and an infinity of other questions that your Product Managers tear their hair out trying to get answers to.
Identifying all the requirements associated with whatever you’re building, including who wants it, what they actually need, what they’ll be satisfied with, timeframes, and an infinity of other questions that your Product Managers tear their hair out trying to get answers to.
Come up with a solution
All the engineering associated with figuring out the “best” solution to the problems that you’ve identified above. Mind you, this is largely a case of multi-dimensional optimization, and there is rarely a “perfect solution”.
All the engineering associated with figuring out the “best” solution to the problems that you’ve identified above. Mind you, this is largely a case of multi-dimensional optimization, and there is rarely a “perfect solution”.
Implement the solution
Here we get to the “Writing Code” part of the entertainment. And no, I’m not giving it short-shrift — depending on what’s being built, it can involve any amount of pain and suffering. Dealing with GC pauses, cache-lines not behaving the way they should, elusive bugs in underlying libraries, oh, this can be seriously painful indeed!
Here we get to the “Writing Code” part of the entertainment. And no, I’m not giving it short-shrift — depending on what’s being built, it can involve any amount of pain and suffering. Dealing with GC pauses, cache-lines not behaving the way they should, elusive bugs in underlying libraries, oh, this can be seriously painful indeed!
Maintaining the solution
Aaaaand, here’s where life get’s interesting. This, my friends, is the long pole in the life-cycle! The thing is, six months from now, you (yes, even you!) will have forgotten what your code does. And yes, maybe you documented your code well, but if you’re a #CowboyDeveloper, the odds are that you didn’t.
What’s worse, the odds are that you will have moved on to the next project, which means that some luckless wight is goin to be sitting there tearing their hair out trying to figure out what exactly your code is doing.
Aaaaand, here’s where life get’s interesting. This, my friends, is the long pole in the life-cycle! The thing is, six months from now, you (yes, even you!) will have forgotten what your code does. And yes, maybe you documented your code well, but if you’re a #CowboyDeveloper, the odds are that you didn’t.
What’s worse, the odds are that you will have moved on to the next project, which means that some luckless wight is goin to be sitting there tearing their hair out trying to figure out what exactly your code is doing.
And that, my friends, is the point. In many (most?) cases, the fact that you generated an ∞ of code can be more about your lack of skills (and/or laziness!) than about your awesomeness. Writing code may be hard, but maintaining code is way way worse!
We’ve all bought into the myth of The Hero’s Journey, that we’ll go through The Ordeal, and emerge victorious in the end.
To us “the end” is when we’ve delivered the code — it’s how we picture us riding off into the sunset, victorious, because the product has shipped!
The reality, however, is that that’s pretty much when the game begins anew. Maintaining the product, adding features, fixing bugs, dealing with unexpected situations that weren’t in the original requirements, oh, it’s a never-ending battle, and it’s where — if your product is successful — you’re going to be spending the vast majority of your time
To us “the end” is when we’ve delivered the code — it’s how we picture us riding off into the sunset, victorious, because the product has shipped!
The reality, however, is that that’s pretty much when the game begins anew. Maintaining the product, adding features, fixing bugs, dealing with unexpected situations that weren’t in the original requirements, oh, it’s a never-ending battle, and it’s where — if your product is successful — you’re going to be spending the vast majority of your time
Internalize this lesson. Remember that the game never ends. And above all, don’t let code quantity turn into a measure of awesomeness!
Note: Another way to look at is is that Code Quantity is proportional to Number Of Bugs (thanks to Cyclomatic Complexity). So, when somebody sez. “Look at all the Code I wrote!”, you should actually hear “Look at all the bugs I created!”.For more, read this article.
Comments