DevOps Zone is brought to you in partnership with:

I'm a software developer working as a senior consultant at Kentor in Stockholm, Sweden. My core competence is as a technical specialist within development and system architecture. In my heart I am, and probably will remain, a programmer. I still think programming is tremendously fun, more than 20 years after I first tried it. That's why my blog is named Passion for Coding.  Anders is a DZone MVB and is not an employee of DZone and has posted 79 posts at DZone. You can read more from them at their website. View Full User Profile

Facing the Brutal Facts

06.11.2013
| 2793 views |
  • submit to reddit

A team in trouble would probably say that they would very much welcome expert help – but would they really? Are they ready to face the brutal facts of the state of the project?

An important part of the psychology behind forming a team is the distinction between “we in the team” on the inside and the rest of the world on the outside. To some extent this is good: A team with a strong spirit will be able to handle any obstacle in the outside world. But in some cases it can backfire, when the team stop looking at themselves, but only look at the outside world to explain problems. In fact; when a team is in trouble, they will in most cases first find external reasons for the trouble.

The customer demanded a huge change, with a very tight deadline.

The architecture in this legacy system is so hard to work with that it takes forever to make changes.

The first one is external – the customer asked for a change, but what about the second? It might be that the system was recently handed over to the team in which case it is external. But what if the team has been in charge for maintenance of the system for a year? The fact that the legacy system that they took over had an architecture that’s hard to work with is external. The fact that they haven’t done anything to it in a year is at least partly internal to the team.

Looking deeper at the first example that might be internal as well. The change may be huge to the team’s standards, but if they had a flexible architecture and proper automated tests in place it might not have been such a big issue. If the team has worked in isolation for too long, they are less likely to see that their architecture is inflexible and that their testing is sub standard.

Bringing in someone new to such a team might be a painful experience. Someone coming from the outside, bringing experiences from other projects will probably point out the inflexible architecture and the lack of unit tests. Doing that is a delicate issue. On the one hand the team desperately need someone helping them to see the brutal facts that they are denying. On the other hand, the team will not be eager to get confronted with those facts, as it turns focus from external issues that are affecting the team, to internal issues that the team themselves can solve.

The Hardest Question in My Career

Several years ago, I was sent to a project that was in trouble. I soon found out that they were in deeper trouble than they knew. Everything was sub standard, but the team were just working along, harder and harder, to deliver on time. They thought that they would have to work harder to deliver. They didn’t realise that the problem was that everything in the project was sub standard. There were no clear goals. There were no clear requirements. There were no architecture. They had chosen the wrong language and platform for the problem at hand and had the wrong people without necessary skills on board.

It was a disaster waiting to happen.

At the time, I had recently joined the company I worked for (my company was partly guilty of the mess) and I didn’t really know yet how my new employer wanted to handle such situations. On my second day in the project a representative for the customer asked me for a private talk. He asked me the hardest question in my career:

Anders, can you please tell me honestly how the project is coming along?

Ouch. Should I tell him that it was a mess – and tell him that my company had failed? Or should I tell him that everything was just fine, like everyone else in the project had said?

I chose to tell the truth.

It was one of the best choices of my career. By confronting the brutal facts we were able to take the right actions to save the project. We basically restarted the entire project six month into a 9 month project with a non negotiable deadline. In the end, the customer was really happy with the work we did.

For those involved in the project however it was a very rough awakening. They had spent months denying to the stakeholders and even to themselves that they had a problem. Now they were confronted with the brutal facts. In just a few days they saw a new team move in to completely take over the project.

In some ways I do feel really sorry for the team. They did their very best. The problem was that they had been assigned a task that was too huge and too complex for them to master. That wasn’t really their fault, it was the management that had set up the project to fail.

Facing the Brutal Facts

Even though management is to blame for the set up of the project, the team is also to blame. They should have asked for help in time. They should have faced the brutal facts that they were falling behind the schedule. They should have stated clearly that the platform and programming language was too hard for them.

The team that takes over a legacy system with sub standard architecture need to face the brutal facts of the amount of refactoring needed – and communicate that to management and the customer.

Hiding in the Comfort Zone

A common strategy to avoid facing the brutal facts is to hide deeply within ones comfort zone. Typical signs of a team hiding is to find them using Visual Studio 2005 or 2008, trailing two or three versions behind. Of course they are using web forms without any kind of partial loading or client side scripts and do all the data access with stored procedures and DataTables. No jQuery, no MVC frameworks, no LINQ or OR-mappers. That’s state of the art technologies – if you’re still living in 2005. The problem is that it is now 2013.

Staying in the 2005 comfort zone is a simple way to avoid having to learn new things. Only to find out after a few more years that there are no longer any jobs to be found with those technologies.

Working as a developer means facing the brutal facts of an ever faster changing world of technology. It means to continue to learn new technologies to stay current. It means to ruthlessly inspect and adapt the team’s practices to continuously improve.

Face the brutal facts – or fall behind.

Published at DZone with permission of Anders Abel, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Lund Wolfe replied on Sat, 2013/06/15 - 2:34pm

The customers may be the first to realize the severity of the project quality problem in maintenance or in new development if it falls behind schedule or important bugs are accumulating.  The developers may acknowledge the bad state of the project but can't fix it themselves.  The project may be too complex and too big a scale with knowledge at the subsystem level but nobody with a big picture understanding who sees where mistakes were made and the options for correcting them.  At some point management will no longer be able to deny the problem and will have to expend resources to do a major refactor or rewrite.

I remember being on a project where we realized a rewrite was in order after only two weeks of new development on a one year project (we were good programmers but very inexperienced in new development).  There was a lot of resistance from above even for that puny time investment.  Your rewrite was successful, but many are not.  Management has often seen multiple failed rewrites of applications in the past and the very idea is painful to them.

As you say, you probably can't trust the same people who wrote the application to do the rewrite or major refactoring or they would have refactored continuously and stopped the degradation already.  You'll have to bring in expert outside help which will be costly.  You also may have to build the new system in parallel if the project is currently in maintenance.  This requires trust, risks, and fears all around.  On the bright side, you may not have any choice, since the alternative of doing nothing is just a slower, if steadier and less agonizing, death.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.