Making money is art and working is art and good business is the best art of all.
–Andy Warhol
Being a software developer doesn’t mean you know anything about the software business. In fact, it likely means you’re clueless. I know this is true, because I made that same mistake many years ago.
Few of us take the time for a “long read” anymore, so I’m going to distill what I have to say into four main points and put them right up front for you. If you agree with them all, then you can just move along. But if you take issue with them, then this “long read” might just give you the perspective that you might be lacking.
Software is full of choices—interesting architectures, abstractions, and implementation patterns that provide an assortment of ways to solve a given problem. And, for those of us that enjoy solving various intellectual challenges, software development is actually quite enjoyable. As developers, we look forward to improving our skills simply so we can better tackle the next interesting technical problem. I’ve often felt that gaining additional development expertise is somewhat akin to advancing levels in a collaborative game that we all thoroughly enjoy playing. And it’s just about as safe and secure as any game.
I quickly found out that business is very different. It’s not a game; it’s real world. It’s rough and deadly serious. It’s about market share, and money, and companies play to win by whatever means they have available. And the rules are very loose. It’s less like boxing and more like a street fight. And in such an environment, you’d best be very careful not to make a mistake. But what makes that especially hard is that often the “right” technical decision will be the wrong business decision. And it’s the business decision that actually matters the most.
Of course to a software developer, like me, it used to be a tough pill to swallow to be told to pick an “inferior” technical solution by my boss. But I finally learned that there are some extremely good reasons to do exactly that. Hopefully, this little example will help illustrate the salient points. Let’s pretend you’re a software developer responsible for implementing a new feature in a software product. Your boss asks you how long it will take, so you do a bit of research to provide an informed response. What you realize is that there are two basic alternatives, both of which will work and look identical to your customer when completed. One implementation approach is very direct, maybe even a little hacky, but will take one day to implement. The second approach is much more extensible and elegant but will take three days to complete. Which do you choose? When I was young I would have opted for the second solution since many would perceive it as more technically “correct” and writing elegant code is actually a bit more enjoyable. So, is there really a problem here if I could estimate the work at three days and then complete it on schedule?
Yes, there is, if I didn’t make my boss aware that there were two choices—as silently choosing the longer implementation time could be a very bad and expensive business decision. Because minimally, I will cost the company an extra two days of wages when I decide to increase the development time by 200% to deliver identical functionality to our customers. Or worse, since I decided to be elegant my boss didn’t know that the team had time to bring a stretch goal into scope that would’ve given our product significant first-mover-advantage and a corresponding increase in sales. See how a seemingly simple technical decision is really a business decision in disguise?
Still don’t “get it”? I’ll let you make the same theoretical choice again, but if you choose to go the 3-day route this time you have to work the extra two days for free. Did that change your decision, or are you perfectly happy working at one-third pay? I can’t imagine many developers would be.
Those of you that understand this lesson now know a bit about how tradeoffs are made in business and why transparency to your management is important, even for what seem like purely technical decisions. And to those that still want to argue with me about the ultimate importance of code elegance and extensibility, I thank you for illustrating bullet points #3 and #4 above.
Perpetual devotion to what a man calls his business, is only to be sustained by perpetual neglect of many other things.
–Robert Louis Stevenson
Not currently subscribing to our blogs? Subscribe now and we’ll let you know as soon as new blogs are available.
