This post was first published on CoderHood as The Software Product “Issue Cycle Phenomenon. CoderHood is a blog dedicated to the human dimension of software engineering.
In the software industry, the average engineer, designer, project manager or product manager stays with the same company for about three years.
This short longevity creates cycles that you can observe if you remain in the same job for at least four or five years. I tend to be loyal to the companies I work for, and my average time in an organization is much longer than the average. That is, I have seen a lot of people coming and going and many cycles go around in a full loop.
Any software that was written more than three years ago is regarded as "legacy stuff," built by people who are no longer around. When a body of work was created by individuals that nobody remembers, a funny thing happens. That work is automatically considered flawed in some way. At that point, people no longer remember or understand the original vision, the product grew away from it, nobody feels ownership or attachment to it, and a strong desire to throw it away and rebuild it grows slowly but incessantly.
The "issue cycle."
I call this phenomenon the "issue cycle." This cycle can be divided into eight phases that loop around in a span of 3 or 4 years. Here is a visualization that summarizes the full loop.
I am going to describe these phases using a theoretical example that has nothing to do with any particular project or product. If there is any similarity with any real situation, it is because this is a common pattern. If you have been in the software industry for a while, you've seen this --- or parts of it --- at some point in your career.
In this example, a company sells licenses of version 2.73 of a software a product that was built years before and that has been maintained by many different people. The original engineers and designers of version 2 are no longer employed with the company. Let's get started.
Phase 1 -- Realization.
It is official! Version 2.73 of the product feels broken. Nothing seems to work well. Some of the known issues have been around for years, and customers are complaining loudly and with increasing frequency. It is becoming hard to deal with it.
The problem is that the issues of version 2.73 are design flaws, not simple implementation bugs. The current design is puzzling, and nobody seems to remember why it was done the way it was done. Only a couple of current employees were around when the design of version 2 was first created, but they forgot the details. Many changes were made since that time, and it's hard to remember what the original vision was and why decisions were made since.
All of this information is documented in backlogs, wiki pages, roadmaps, bug reports and a pile of loosely organized high-level specs. In short, it is everywhere and nowhere. Reconstructing the history is almost impossible, and reconstructing the original intent is absolutely impossible.
An alarm bell goes off. Someone decides that something needs to be done to fix it. Let's rebuild it! Everybody agrees.
Phase 2 -- New vision.
A group of people takes responsibility for the project. They call it version 3. It is going to be great. Everyone is excited. The team develops a whole new vision for a much-improved version of the product. Considerable attention is given to ensure that all the existing flaws are addressed.
The group discusses the vision in high-level strategic sessions. Engineers and UI/UX experts meet until all the high-level design aspects have been sorted out. Product management organizes focus groups and incorporates their input in the design. The stakeholders write documentation to remember why decisions were made.
The engineering team builds the new product using agile methodologies. They build functional pieces, making decisions along the way, and releasing it in small batches.
A couple of engineers leave the company, but management quickly replaces them. No big deal.
Phase 3 -- Success & Celebration.
One day, version 3.0 is finally ready. The team built and tested most planned features, and a small group of users has been providing feedback all along. Release day comes and goes, and everyone cheers.
The new version seems much better than the original. It fixes all the existing problems, and a big weight is lifted. The project team is a hero for the day.
One of the UI designers finds a new job, but she documents all of her thinking and ideas before disappearing. It's business as usual.
Phase 4 -- The new normal.
People forget about version 2, and version 3 is the new "normal." The initial excitement vanishes slowly. A dedicated team maintains the product, and things seem to be well under control.
Version 3.1 is released.
Often you hear people say, "I wonder why we did it this way," but the concerns are minor and easily answered.
Version 3.11 is released.
The principal designer of version 3, the "go-to-guy" for most design-related questions, is fired for undisclosed reasons. People speculate, but nobody knows what happened. He leaves no documentation, no notes and a whole bunch of unanswered questions.
Phase 5 -- Growing pains.
The issues of version 3 start sticking out like sore thumbs. Customers complain, and solutions are cooked quickly and released to stop the bleeding.
Version 3.15 is released.
The engineering team maintaining the product is new to it at this point, and they work with the information they have. Documents are hard to find, and internal knowledge is slowly getting lost.
Version 3.2 is released.
The chief engineering manager gets hired as CTO for a different organization. The company replaces her, but it takes a few months and there is some significant struggle to keep things moving smoothly. Some more churn in engineering is inevitable.
Phase 6 -- Fixing frenzy.
The new manager gets to work and ensures that a very efficient group of engineers take care of fixing the acutest issues. Less severe issues are de-prioritized and left untouched. New designers modify the user experience to respond to customer complaints, and things move along quickly.
A series of releases address issues systematically. Version 3.2.1, 3.2.2, 3.2.3 and 3.2.4 are pushed out the door in two months. The team is on a roll. Heros are born. Hugs all around.
Phase 7 -- Shaky foundations.
As the new people learn how to be efficient with the legacy code, new features are added on top of existing issues. At this point, the people who created the product are not around. They left months ago. There is almost no memory of the original vision, and decisions are made without understanding the original thinking and unwritten design guidelines.
Version 3.5 goes out with a ton of new features and a huge marketing campaign. The market reacts with mild interest.
Phase 8 -- Loss of vision.
The problems of version 3.x start feeling bigger and bigger. The new features do not work well within the boundaries of the original vision. They look and feel like a bad remodel, breaking the 3.0 design in unexpected ways.
Nobody is around to defend or explain the version 3 vision, and the product starts feeling broken and clumsy. Customers are not happy.
Rinse and Repeat
The cycle starts again from phase 1.
The root of the problem.
The issue cycle is due to the loss of vision that occurs when employees leave a company and are no longer there to maintain a design consistent. Fresh ideas are a good thing, but a loss of vision can be dangerous and expensive if it is allowed to deform a self-consistent model based on specific and forgotten principles.
New people want to put their mark on products, and (subconsciously) leverage existing holes to create cracks where they inject change; this is not necessarily a bad thing if done well. It is part of innovation. However, too often it doesn't go well.
What can you do to avoid the issue cycle?
The issue cycle is natural and almost inevitable unless it is understood and deliberately addressed. Here are a few things that can be done to avoid it.
Write the book of design principles.
You can stop the issue cycle by ensuring that future generations of developers and product managers understand the original design and vision. Passing down that knowledge is not easy. It should not be accomplished by writing hundreds of pages of documentation. Nobody will read it. Instead, it should be achieved by writing simple, clear and concise principles and guidelines and by sharing it in ways that can be easily found and referred to in the future. That document is a "book of design principles," that must be easily found and often referred to from all other documents. I call this a "book," but it should not be longer than 3 or 4 pages.
Give your key people reasons to stay.
It is good for a company to have some employee churn, let in new ideas and let out stale dogmas. However, a 3-year 90+% employee churn is at the core of an issue cycle and it is not healthy.
The visionaries who create a product carry a vision and its torch. If you can, and if they continue doing good work, treat them well and encourage some of them to stay. Avoid to fall into the "3 years average tenure," and try to make sure that there are continuity and innovation across generations of employees.
Stay focused on design.
Quick-wins are the hallmark of new employees who join the company and want to establish their reputation. it is a natural tendency, and it is not unhealthy as long as they understand the vision of the product and the principles on which it was built.
Software products devolved when their evolution becomes a long series of quickly added features. Make the product design-centric, not feature-centric. Use the book of design principles to keep the design consistent, and never allow a proliferation of quick wins to pollute a well-crafted design and product vision.
Accept the inevitable refresh.
Technology evolves, and eventually, all products need a significant update. It is inevitable and healthy, as long as the process is controlled. Do not let a series of mistakes, or the devolution of the design, to dictate when a refresh is necessary. Instead, initiate a refresh with a new set of design principles before it is too late.
As a rule of thumb, you should still be able to recall the design principles of the previous version when you start crafting the design principles of the new version.
Don't let implementation define the design.
It is very tempting to let implementations define a design, especially in engineering-driven organizations or in organizations where quick-wins are the only thing that matters. When you accept such compromise, the design devolves. That is precisely the reason why quick-win feature-based evolution tends to result in a bad user experience. Sometimes quick-wins are good, but it shouldn't be the only way you approach product innovation.
That is precisely the reason why quick-win feature-based evolution tends to result in a bad user experience. Sometimes quick-wins are good, but it shouldn't be the only way you approach product innovation.
Do not let people who don't understand the product design features.
If new employees are hired, and they are not familiar with the book of design principles or the product, they won't be able to start creating new features. If they do, the results will be most likely suboptimal. It is important for new employees to understand the design principles of a product before they can make good choices.
A classic red-flag to watch out for is a new hire, especially a product manager or product designer, ideating and pushing for features without asking questions about the existing product and its vision.
Evolve the vision deliberately, not just the product.
When you grow a product beyond the original concept, you need to redefine it. Without vision, products tend to take an erratic path.
Make sure that you maintain a clear vision alive at all times, and revisit the book of design principles accordingly. Do not devolve in consistently accidental innovation; innovation should be deliberate and planned.
If you enjoyed this article, keep in touch!
- Find all my posts on CoderHood.
- Join my professional network on LinkedIn.
- Follow me on Twitter.
- Join my Facebook page.
- And finally, follow me here on dev.to!
Latest comments (5)
I've seen the same pattern time and time again.
In my opinion, where things go off the rails is in Phase 1. The allure of "Let's rebuild it! Everybody agrees."
It's tempting. It's appealing. It's exciting. I've even seen it done successfully.
But it is extremely high risk.
Robert Martin's Chapter 1 of Clean Code and Joel Spolsky's post Things You Should Never Do discuss how dangerous such a decision can be.
Even though I admit I, too, am tempted by the joy of greenfield projects -- for pragmatic reasons I'm far more in favor of "work with what you have; renew, renovate, and refactor from within incrementally" rather than "throw the baby out with the bathwater, and start fresh".
Yes! I completely agree.
From personal experience I would add a few things:
Some people have a vision. But most people are followers. If you ask them, they just get the most popular trend of the time or just continue what they were doing before regardless of the actual requirements of the products.
Out of the people that have a vision, many never tried it. Many can't really follow it or deliver and if there presure they'll completely forget it.
In general most people just do the quickest thing that can possibly work. Copy/paste, not really thinking of performance or maintenability. They don't write documentation. They don't really document. They add more to existing class/method/module/git repo without ever take the effort to refactor. The naming is clumsy at best.
Management and companies want to think we are all equals and replacable. They will move people to different teams, put the new comers on the critical task, ask for impossible deadline and want it to just happen without recognizing any specific talent to their employees/subordinate. They focus on pleasing their boss to get promoted to a different job. They don't really care about the company, the product.
The guy/team that get the project is the one with the best communication skills, best PPT, best political skills. As products take years to be implemented by the time the reality is visible to the management it is too late. Many of the most well seen guys already got promoted and the management that let it all appear want to hide the issue.
You can be yourself, your team, your boss as great, motivated, efficiant as you want, willing to work 60hours a weeks for years, you'll always be dependant of other people, managers, policies etc that will eat budget and produce nothing or will explain how you have to do your job while they have no idea what it really is. Even if most things where done right, the little small thing enforced by another team/guy will manage to kill the project, make it late by months or even year and double or triple the total cost.
This is such a great post about something I have observed (and participated in). It has encouraged me to start a centralized design book.
Excellent!!!