"Guys you will never have a chance to build the version 2.0, you have to get it right from the get-go, or keep suffering from your mistakes for the lifetime of the product." - Jiri Karpeta, my boss at LCS International, used to say. It was back in 1995, and while LCS's bread and butter were Helios, an ERP for the SMB segment, we were busy building Noris - the future LCS's flagship ERP for larger enterprises. Of course, given the above philosophy, LCS was quite heavily invested in CASE tools to support our software design efforts. That's where I learned the first time that software modeling matters.
But back to the original statement above that you "never get a chance to build the version 2.0". It may sound too harsh, too fatalistic. Well, you may be right, there are always exceptions to the rule. While I don't have exact statistics at hand, my experience shows that the statement is more often correct than not. I have interviewed hundreds of software developers throughout my career and quite often when asked "Why are you considering to leave your current company?" a story like this unfolds:
"We have an old legacy system. It is difficult to extend, and some features are almost impossible to add because it was poorly designed. We decided to write a new system to replace the old one. We spun off a separate team to drive the effort and kept the rest of the team to cater to the existing customers and maintain the legacy system."
Now the story usually breaks into two buckets, depending on where the developer being interviewed resides:
"Unfortunately, I am working on the legacy product. The other team has all the fun building the new stuff, and we are stuck with the old codebase. It was supposed to be a 6-month project, but we are 18 months into it, and there is no light at the end of the tunnel. I am getting tired of waiting until I will be able to switch to the new framework."
Or:
"I am working on the next-gen product. We are a small team which was supposed to be dedicated to building it. Things got a bit more complicated than we anticipated at the beginning and our management lost patience, my peers and I are frequently pulled away from the new project helping to develop feature requests to the legacy product for our key customers. This slows down the new product development, and I am not sure that the leadership is still really committed to building it. I am tired of having to fight for resources."
I listened to the above story too many times to dismiss it easily. Most companies, who like LCS need to continually deliver value to its customers to earn their living, can hardly afford major product rewrites. It takes enormous energy, effort, and discipline to pull this off and only a few companies can actually afford it without threatening their very existence.
A great example of the importance of getting the fundamental's right is the GoodData architecture. It was devised back in 2007 by a small group of people led by Michal Dovrtel, company's co-founder, and it laid a very modular foundation for the GoodData platform. Throughout the years, we rewrote pretty much everything - the middleware infrastructure, the central configuration, and directory database (C3), the web layer. We replaced the database backend several times going from MySQL to PostgreSQL to Vertica. We even rewrote the heart of the system - the analytical query engine (AQE) itself.Yet the architecture fundamentals remain intact until present days. All the above happened while serving the customers and growing the platform. The key to success was precisely the fact that we were able to rewrite all the components per partes - a component by component - while not having to change the underlying principles of the platform architecture. The team involved in the original design had a profound understanding of the problem domain and was thus able to come up with the right abstractions which remain valid even after ten years since inception.
So let me rephrase the opening differently: "Guys you will seldom have a chance to build the version 2.0, you rather get it right from the get-go, or most likely keep suffering from your mistakes for the lifetime of the product."
Check out the previous post in the series Agile on Overdrive.
But back to the original statement above that you "never get a chance to build the version 2.0". It may sound too harsh, too fatalistic. Well, you may be right, there are always exceptions to the rule. While I don't have exact statistics at hand, my experience shows that the statement is more often correct than not. I have interviewed hundreds of software developers throughout my career and quite often when asked "Why are you considering to leave your current company?" a story like this unfolds:
"We have an old legacy system. It is difficult to extend, and some features are almost impossible to add because it was poorly designed. We decided to write a new system to replace the old one. We spun off a separate team to drive the effort and kept the rest of the team to cater to the existing customers and maintain the legacy system."
Now the story usually breaks into two buckets, depending on where the developer being interviewed resides:
"Unfortunately, I am working on the legacy product. The other team has all the fun building the new stuff, and we are stuck with the old codebase. It was supposed to be a 6-month project, but we are 18 months into it, and there is no light at the end of the tunnel. I am getting tired of waiting until I will be able to switch to the new framework."
Or:
"I am working on the next-gen product. We are a small team which was supposed to be dedicated to building it. Things got a bit more complicated than we anticipated at the beginning and our management lost patience, my peers and I are frequently pulled away from the new project helping to develop feature requests to the legacy product for our key customers. This slows down the new product development, and I am not sure that the leadership is still really committed to building it. I am tired of having to fight for resources."
I listened to the above story too many times to dismiss it easily. Most companies, who like LCS need to continually deliver value to its customers to earn their living, can hardly afford major product rewrites. It takes enormous energy, effort, and discipline to pull this off and only a few companies can actually afford it without threatening their very existence.
Future-proof Architecture
But you never get everything right on the first attempt, do you? The answer to the problem is not to do everything right in the software architecture. The answer is to understand the product domain and problem space well enough to get the basic foundations right (the backbone) while making the architecture modular, with clearly defined interfaces and contracts between components and layers, so that you can adjust and refactor the product incrementally, piece by piece, rather than having to throw in the towel and start aiming at 2.0 while sitting on a heap of spaghetti code, where everything depends on everything.A great example of the importance of getting the fundamental's right is the GoodData architecture. It was devised back in 2007 by a small group of people led by Michal Dovrtel, company's co-founder, and it laid a very modular foundation for the GoodData platform. Throughout the years, we rewrote pretty much everything - the middleware infrastructure, the central configuration, and directory database (C3), the web layer. We replaced the database backend several times going from MySQL to PostgreSQL to Vertica. We even rewrote the heart of the system - the analytical query engine (AQE) itself.Yet the architecture fundamentals remain intact until present days. All the above happened while serving the customers and growing the platform. The key to success was precisely the fact that we were able to rewrite all the components per partes - a component by component - while not having to change the underlying principles of the platform architecture. The team involved in the original design had a profound understanding of the problem domain and was thus able to come up with the right abstractions which remain valid even after ten years since inception.
So let me rephrase the opening differently: "Guys you will seldom have a chance to build the version 2.0, you rather get it right from the get-go, or most likely keep suffering from your mistakes for the lifetime of the product."
Check out the previous post in the series Agile on Overdrive.
Comments
Post a Comment