When you think of product development and software development what comes to mind?
For many people, their answer is usually:
“There’s a difference?”
But, in order to truly understand the distinction, we need to travel back to the 1960s during the infancy of computing.
History
Back then, when a computer as large as a building was 100 times less powerful than the original iPhone, software engineers had no choice but to be meticulous in their architecture and design. Every software system had to be broken down into carefully defined and reusable modules if they ever hoped to get the software to run at all. It’s also important to remember that fixing a mistake wasn’t as easy as hitting backspace. Each line of code was encoded into a paper punch card. If one keystroke was wrong, they had to start all over again.
So, at the dawn of computing, writing code was very difficult and it required an extreme level of discipline. Every line of code had to be highly efficient, and all of these constraints required experience and care in design in order to write software that actually worked as expected.
Compare that to today, where a 10-year-old can watch a few videos on YouTube and start writing code that runs in the cloud. It’s easy.
But more than that, it doesn’t require any discipline.
And when you’ve got more computing power in your pocket than you did in that 1960s computer that took up an entire building, you suddenly realize there are no limitations to what you want to do. After all, why should someone care about architecture, modularity, efficiency or precision when writing code is so very easy?
Answer: they don’t.
The difference between a piece of software that was built for internal use and developed to automate a business process inside of a corporation, versus a software product designed to do the same for customers to generate revenue, is that the product has to be built to last. It has to be built so that it can be sold and ultimately maintained for years so you can recoup your investment costs and then some.
In other words, profit motive is a key differentiator.
If you’re a Fortune 500 company with your own R&D team, you’ve got developers writing code to help you run your business better. Obviously, you’re not selling any of that software which your team created, nor are you tracking it to see if it’s making you a profit. But, you might be tracking to see if it’s effective.
For the software development team, internal company departments are the primary customers. Idea generation and market sizing exercises are much more centralized, and the development life cycle is even different. For product development teams, user acceptance, product market fit, and proper testing can be the difference in the success of the company.
It has striking similarities to the difference between a car and an airplane. The car may have a lifespan of 10 years and 100,000 miles, but is designed to eventually wear out. The airplane, however, has a lifespan of millions of miles and can easily last 30, 40 years and still be safe and reliable. How is that possible? Because it was designed to be maintained over the long run.
That’s the fundamental difference between a software product and just a piece of software.
Culture
Culture also plays into these differences. The culture around internal software development is vastly different than the culture around commercial software product development.
And that’s ok…because it has to be.
Developers often drive and own the technology road map. They’re the ones who decide what goes in the next version or the next release of the software (this is a topic for another article or three). For them, it doesn’t matter if software development is a profit center or a cost center. They’re only focused on the next new feature, function, or technology that they can dive into. This is to be expected because they’re not being measured on the revenue generation potential of the software they write–only the next deliverable they can produce for internal consumption.
The typical software developer has no problem writing and re-writing the software every few years because she loves it. There is always a new challenge; something new to try; something intriguing to expand upon.
In my eyes, the profit motive and customer base is the white picket fence that separates the two families.
As I said at the outset of this blog, people tend to use Software Development and Product Development interchangeably. But, as I’ve shown, software development can exist without a focus on design or discipline because it’s so easy to write code these days.
This bifurcation really accelerated in the early 90s when Visual Basic came out. Microsoft had suddenly made it so easy to write code that anybody could do it. It was very democratizing.
Trust me, I’m not complaining. Because I believe it’s a good skill to have.
When you need to develop a product, a commercial product, which you need to sell for profit, and you need to actually generate a recurring revenue stream, the discipline and design that must go into R&D is on a whole other level.
How can Modularis help?
At Modularis, commercial software product development is in our DNA. PlatformPlus is designed exclusively to help software engineers de-risk and accelerate the construction of commercial software products and platforms.
Software product development demands a high degree of discipline and an even higher degree of architecture and design. Without those you will not be able to deliver a commercially viable software product which will stand the test of time, which will be easy to maintain, and which will continue to deliver a solid return on your investment.
It’s those two things that we can provide better than the rest. With PlatformPlus, you get the fundamental design and the fundamental architecture you need for any commercial software right out of the box.
Plus, the model-driven automation component of our platform is very design-centric, and enables you to design your application, product, and platform before you ever build it. The technology injects both discipline and proven design patterns into your software R&D organization, so that even if you have a team of software developers, we can help turn them into a team of software engineers.
Reach out to learn more today.