Story about Software Lifecycle

This is a tale of a software lifecycle. It's fiction, but into what extent - I won't tell. It has been inspired by real events.

The Beginning 

About seven years ago a big consumer company wanted to renew their customer web portal. They didn't have own software development department, so they hired a team of external consultants for the task. Consultants came from two different companies. One was a smaller company with senior specialists. They did the architectural design. The other company was bigger. Already from the beginning the plan was that the bigger company would maintain the portal. Their developers were less senior, but the plan was that they would learn during the building phase.

The portal was a big success. It even won prices. When the intensive building period was over, the smaller consultancy company went to do other things and the other company began to maintain the portal. From now on I'll call them supplier (or team A).

For quite a few years everything went well. there was one person on the customer's side who was in close contact with the supplier. Supplier had a dedicated team and an architect/scrum master. New features were being built and things worked smoothly.

Maturity

Time passed. The customer relationship was so intense that at one point the architect needed to blow the whistle and take some time off. The person was replaced by another architect. The developers who were involved in the early phase were also in the early phase of their careers. And it is quite understandable that after a few years they wanted to do something else. Some changed roles, some went to work in other companies. If you are familiar with the job market in software industry today, you know that there are plenty of opportunities for skilled developers. People can easily vote with their feet. From maintenance point of view this is a real pain.

New people, who weren't familiar with the codebase, had a big struggle getting into productive mode. Without really rigorous attention to architectural quality, software tends to get more complex and more difficult to maintain. And when this is combined with staff turnover, the overall architectural picture gets lost.

Unfortunately, when there are no senior members in the technical staff, the balance between business and technological needs gets disturbed. Business grieves features and visible things. For the business, development speed (how many new features you get with x amount of money) and performance (how quickly things happen when you click) are relevant. What happens behind the scenes is not. The development team should speak out for the technological needs.

There's a dependency between development speed and codebase complexity. With low automated test coverage and high coupling, introducing new changes is always a potential source of unwanted regression. But for a person observing the development from the outside, this simply appears as slow and costly development that produces poor quality.

Back to the story. The customer didn't want to spend so much on the maintenance and so the supplier scaled down the size of the development team. Or the team size was kept about the same, but they were working for another customer. Organizational changes happened on both sides, with the customer and with the supplier.

The customer was unhappy with the development results and felt that they needed to take a tighter control. Team was heavily micromanaged. Daily scrum meetings turned into reporting and command and control sessions. The development team didn't like this and it accelerated the staff turnover even more.

The Renewal

The supplier had seen that it was getting very difficult to find people who were familiar with the technology. Without consulting the customer, they made a plan how to renew the portal to current technology. The benefit would be that there was much more skillful labor available in the job market and that the development speed would increase dramatically. The software architecture had deteriorated into a big ball of mud, but by applying certain changes, the user interface could be separated.

Due to the understandable lack of trust, the customer had hired an external consultant to aid them in technological decisions. Actually this person was also one of the people who originally participated in making of the original portal. Thus he knew it well and didn't see a need for changes. The supplier was trying to push the idea, but things got postponed. After six months, the supplier had hired a technology guru who could fluently demonstrate how the changes could be implemented. It changed the customer's mind. The plans were the same, they were just presented smoothly by a charismatic person.

When the renewal project finally got green light, the customer insisted that there would be a "dream team" working on it. There would be team members from the supplier (let's call them team A) and team members from the other smaller company (let's call them team B). Architect and scrum master were appointed from the smaller company and the customer acted as the project manager. Customer strongly demanded that the development should take place on site, in team B's premises. 

Before the actual development started, there were planning meetings where the plan was discussed, argued and fought over. Architect from team B questioned all design decisions that came from team A. During this period both the technology guru and the most senior developer in this new technology resigned. They had made their decisions about how fruitful the co-operation between the companies would be and didn't want to live in continuous argument.

Team A had had a team lead who was the main contact between the customer and the supplier. But for this project the customer said that they didn't need his services, since the customer's own representative was managing the project. Team A also had an architect, but he was stripped of his power, since the achitect was appointed from team B. During all this time, team A was still contractually responsible for the portal.

Teams didn't collaborate that well and the project fell into crisis. Even though there had been numerous planning sessions before the project started (that were mostly used for arguing), the plan regarding the user interface was still rather abstract. Stories had not been refined and for example the styleguide for the whole site was only one story. The work estimates were too small, since they were given by more senior people than who were left in the team.

The End

The team lead, who wasn't needed for guiding the project, resigned. This wasn't communicated with the customer. Soon the whole renewal project was cancelled. The customer made a decision that they would end their contract with team A and team B would maintain the portal in the future.

Learnings

There are probably quite a few things to learn from this and mistakes were made in many occasions. But here are at least some takeaways:

• Pay attention to technical quality. Feature development is important, but without proper code and architectural caretaking software will rot over time.
• Technologies have lifecycle too. I dare you: try to find COBOL or Smalltalk developers. Make a plan for renewal early enough.
• You catch more flies with honey. If you want people (your own employees or suppliers) to walk the extra mile, treat them properly. Collaborate rather than command.
• Or from the supplier perspective: if you are faced with a challenging customer relationship, add a buffer role into the interface. Some people might even enjoy the challenge.
• Don't pit suppliers against each other. Rather insist that they collaborate.

End note: Hopefully the story made you think. If you see events around you that resemble this story, be careful. It's never too late to change the direction ...until it's too late.

Photos by Ariel Besagar, chuttersnap, frank mckenna, Matt Botsford & Filip Mroz on Unsplash