Product Software Development is a Marathon
Software development demands focus. You can’t create anything significant hopping from one thing to another. That is obvious. Less obvious is that product development demands patience.
Service development is different. In most cases you have a project with a visible end. It may be a year long, or even several years long. But still project will be completed someday… Or abandoned. Most service products are sprints. Clients pay you money and they want to have something as soon as possible. They radiate the impatience. They set deadlines. They resist to invest much into good engineering practices like automated tests. Yes, you negotiate all that and sometime with a success, but still it’s quite hard to sell a great development process to the customer. So you rush, cut corners, drop some good practices to save time and argue about change requests. Agile approach helps to solve some of these problems, but you still feel the constant pressure. And rush anyway.
This strategy doesn’t work for product development. It takes a decade or more to create a truly remarkable product. Constant rework, constant improvements, constant polishing and learning. You fail, learn something new, improve things and move forward. It just can’t be done without patience.
Suddenly you understand that great thing takes time and it changes your attitude. You learn how to run with a steady pace, maintain energy level and endure the race. In a sprint you have no room for any mistake. Even a little mistake will cost you huge. In a marathon you have time to fix problems and still win.
If you are in a product development business, I can give you several advices:
- Learn how to learn. This road takes many years, you need knowledge to solve problems and invent things.
- Learn how to wait. It is so fucking hard to me.
Sometime I feel enormous pressure to speed everything up and run at a
full speed. But I realize that it will drain all our energy and
development team will be exhausted and washed out. We’ll start to lose
people. Morale will go down. That’s not a viable strategy.
- Embrace re-work. Most likely you will have to
re-write some parts of the system 3-7 times in the next several years.
You should be ready to do that. Re-work is good. It makes things better.
- Ship early.
You may think that now I’m a 100% perfectionist who will kill for the
1px design mismatch in a latest release. That is far from true. I like
to ship things as early as possible to some closed group of customers at
least. For example, we are working on v.3 of our product
during the last 15 months. It is still not public. However, we had
first users 9 months ago. Currently around 600 people from 100 companies
are using v.3, we have constant feedback and make improvements based on
Remember, that most people can run a 100 m distance, few people can run a marathon.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)