A Few Thoughts on the Economics of Software Product Development
Some of you probably already get this… some of you might even disagree… but unless you are building software as a hobby… chances are, you building software for money. In other words, someone is paying you to write software for them.
Why would someone pay you money to show up and write software? They are paying you money to write software because they hope to sell that software and get even more money in return. It is an investment.
Ideally, we should want our investors to get a good return on that investment so they’ll keep investing. It’s our job as software professionals to help our sponsors get good, working software into the hands of paying customers as quickly as possible. That’s how we make money.
The act of selling software funds our ability to build more software.
Conversely, our inability to sell software makes investors grumpy and a lot less likely to want to keep paying you to write software. Unless we sell software, we don’t have any money to pay people to build software.
To many, the thought that we are writing software for money cheapens our craft… it cheapens our art. We want to be pure. We want to build perfect products. We want to perfect our craft and be artisans.
Don’t get me wrong, I’m all for building great products. That said, at some point, we have to strike a balance between perfection and getting products to market, products that can sell and start generating revenue.
Why am I writing this post?
Over the past few years, I’ve worked with a bunch of folks that have seem to have lost this fundamental connection to the economics of software development. Some where along the way, software became and end unto itself.
…somewhere along the way it became more important to be great engineers.
…somewhere along the way it became more important to be great testers.
…somewhere along the way the design became more important than the delivery.
Some where along the way, it became more important to deliver everything at one time rather than to getting something into the hands of our customers as quickly as possible. I think that mindset is killing many of our companies.
If you were spending your own money to build software, you’d want to see a return on that investment as quickly as possible. As software professionals, we have to start thinking about the economics of software delivery and act accordingly. How would be build software if our own money was at risk and failure wasn’t an option?
Comments (13)
JacobM
It’s probably worth pointing out that many developers are not, in fact, writing software that is going to be sold for money. My guess is that a large fraction and possibly the majority of software that gets written is for internat use by companies and other organizations (I write internal software for a university).
It’s hard to see how anyone could disagree that it’s best to strike a balance. But I do think that you’re leaving out a significant part of the developer’s job — when we sell or deploy or otherwise deliver a piece of software to a customer, our job is far from over. There will certainly need to be maintenance, enhancements, integrations with new products, etc. If we strike the balance too far on the side of getting-to-market (rather than crafting the software well) then the after-market portion of the development process will suck for everyone. That does no service to the customer or the company.
I might suggest that you actually are writing software for money… the path to the money is just a little more indirect. You receive money for the software you write. The software supports some internal group that receives a budget from the university. That budget comes from students who attend the university. Their experience with the university is made better (or not) by how well your software supports the operations of the university. If your software is not enabling the university, they are not getting students, they have no money, they don’t fund more software projects. Oversimplified I am sure, but you get the point.
I get that it is a balance between short term and long term needs of the product. I think it is totally valid for a product owner to decide though that they would rather have more features in the product, even if the product cost more to support, as long as the economics of that tradeoff make good financial sense. The answer to that question can go either way, but the question has to be asked. The long term needs and supportability of the software don’t always justify delaying a release.
I wrote this post somewhat in response to a session I did yesterday with a very small company that was chasing the perfect architecture and the perfect product at the expense of getting something to market. They risk their investors deciding the product is not worth the risk… they need to get something to market to get feedback and revenue. If they don’t start making money, they don’t get to write software. In many situations… even yours… I’d suggest that many of us forget that simple fact. Therefore my post. Thanks for your comment!
JacobM
Fair enough. And of course, one of the advantages of going quickly to market is getting feedback, assuming that your software is malleable enough (i.e. well-crafted enough) to be able to easily respond to the feedback. We definitely do that; we don’t have “market”, but we try to release to users as soon as we have something of value.
I’m sure that experiences vary a lot. If I were confronted with a team that wouldn’t release because the code wasn’t perfect, I’m sure I’d have your reaction, but in my own experience I’ve seen the opposite (take shortcuts, code things sloppily, skip writing automated tests, all so that you can release faster) far far more often.
Yeah, that’s the challenge with blog posts… experiences vary, context varies. What it really boils down to for me is that even really good developers, not just the sloppy ones, have a tendency to see everything as one big glob and struggle to break things into releasable pieces. There is a belief that it is more efficient to code things together rather than release and refactor. Product Owners want to release everything at one time for different reasons. They struggle to find the MMF or the MVP. Testers want every corner case covered… etc. etc. Great conversation, thanks for the follow-up post.
Henry Miller
My company does the best it can to hire the best engineers and make them better. They do they best they can to test the software I write in all possible ways, part of which is having the best testers. They are very concerned that the software I write is well designed.
The company has traditionally been concerned about great engineers – we have 175 years of reputation for quality, and we know from experience that great engineering is one factor in keeping that reputation. Like wise testing is important – we cannot sustain our reputation for long if we release junk.
Design is becoming important as well. The company has come to realize the poorly designed system with a lot of technical debt is no longer cost effective to add the features our customers want to buy. We are spending millions of dollars on a redesign, and the constant concern is we how can we make it as long as possible before the next big start over.
The customers just want to get their job done at the end of the day. They would prefer N features that work, over N+1 features that do not work. This even though they want N+1 features and are willing to pay an several thousand for that one extra feature we will not deliver this year. (Maybe next release – business is always trying to decide which feature is worth the most)
Henry… of course good engineering, good testing, and good design are essential. Hopefully your company has found a way to do all that AND release early and often. I guess you’ve struck the right balance because your company is still in business.
Bob Williams
As I think about it, the mindset of producing a single “do it all” release was a necessity in the past when software was distributed on floppy disks and CDs. That was just a result of the economics of software distribution. But conveniently, it fit the waterfall SDLC and the traditional software delivery mindset as well.
The internet, broadband access, and mobile devices have changed the game. Companies now have the flexibility to release incremental features and updates with a lower cost of distribution. The focus should be on the customer need, not paperwork and processes.
Peter Graves PMP
Mike – you might also add
…somewhere along the way it became more important to be tinkers (what happens if I do this or this)
…somewhere along the way it became more important to over-engineer
Keep up the great posts and books
Dragonheart9
JacobM, you said the magic word — VALUE. And, VALUE is in the eye of the consumer, and the money follows. As a Product and Project Manager, I think VALUE needs more focus. Money is just a means to quantifying the value — who, what, when and how much $$. Just my thought.
June Adams
A very well written article. Thanks for sharing!
Dakshitha
Hii, Nice Article. Its great to read this article , very informative. Thanks for sharing !