Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn
Profile photo of Todd Williams
Todd Williams
VP of Technology and Co-founder. Decades of scars from software development and the business surrounding it. Follow @toddewilliams for musings.

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.

  1. Business competition is very intense and making a big mistake can kill a product or a company
  2. Technical decisions affect the business since delays or feature slips affect sales and credibility
  3. Software expertise is completely different than software business expertise
  4. It is very difficult to explain any of this to software developers

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.

Related Posts

Do Hard Things: A Lesson from a Wilderness User Me...  George greeted me with a smile and handshake as I walked into his camp out in the Colorado wilderness. Little did I know how important this day would become to me and MyEclipse, the product for which I was the product lead. Over the years our products have been adopted around the globe. Meeting with developers and learning how well our dev to...
Let Them Storm the Beaches Getting old really sucks. Running is my stress relief. It is also my feeble and losing battle with time. My 45 min running route gives me a 2 mile reprieve onto the soft sand along the beach. With summertime upon us, kids dart in and out of the water with too much joy in their eyes to pay any attention to anyone or anything moving along the beach. ...
The Virtue of Failing Fast I have not failed. I’ve just found ten thousand ways that won’t work.— Thomas Alva EdisonThis comes as no surprise, but not every idea will be a winner in the marketplace. We all fail sometimes, for a variety of reasons, some within our control and some not. And it's common sense to learn from those failures. But within Edison’s guidance is a true ...
Create a Note Taking App Using Angular In this Angular tutorial, we are going to create a Note Taking App using Angular IDE.Create New Angular ProjectWe’re going to be using Angular IDE in this tutorial, though you can use Webclipse or MyEclipse, following exactly the same steps. Before beginning, do ensure you are in the Angular Perspective (Window > Perspective > Open Perspectiv...

Posted on Jul 20th 2016