My rant about legacy code

"Ya ni llorar es bueno", this is a Mexican saying that translates to "it's not even worth crying anymore". I thought about this saying after a talked with few companies and friends regarding legacy application, specially legacy code that directly hit the ROI of the company. To add some context around this post, let me explain what does "legacy code" means to me:

• It is using a technology relatively "old" (+5 years)
• It is in production
• The application plays an important role in the company

I have worked on a few of these applications and I hate most of them! Not because the they are hard but because of politics. It has been my perception that managers are "gun shy" when it comes to handle the re-write of legacy code when they are clearly out of control. I am not sure why this is, but this are some my reasons based on my interviews with tech leaders and developers:

1. Time: aah, the Pandora box of managers. Lets face it, it is hard to estimate software projects, and worse the re-factoring of a major legacy code. The stakes are high if the re-factoring goes wrong. Managers have mentioned that these refactoring are a double edge sword because it can be really good, or it could eventually damage their reputation and the morale of the team.
2. Resources: many manager are fighting with other departments when it comes on resources/programers. Many companies are trying to innovate and create new applications to latch on to the new business models. These projects take priority over the legacy systems that they have in place (if it's not broken, don't fix it).
3. Domain experts: many of the large dev shops (+20 developers) have two types of development departments: engineer and support. The engineers are senior developers with at least 5 years of expertise. They develop the application based on the specs of the project manager and product owners. The support team are a mixture of junior and junior-senior developers. They take over the code when the engineers deploy the application to production. The problem with this model is the lack of mentoring/couching of the junior team. The support team does not have the know-how or the domain expertise as the engineers. The consequences are the introduction of bad code or bad practices when they need to add a feature or fix a bug.

Some of the dark side of the legacy codes are the following:

• Bloated controllers and DAOs
• Business logic is ALL over the code (DAO, stored procedures, controllers, DTO, the list goes on)
• Silo effect - just a few developers know about the application
• Fragile code - tightly coupled code
• Bug identification and turn-around time is large
• Application is slow

I doubt that I can get the right answer to this problems, but here is my advise to current and aspiring managers regarding this matter:

1. Bite the bullet: if the legacy application is a major part of your business, don't wait any longer. Get a grip on this application before it get any worse and start doing a re-factoring by doing small iterations (not longer than 2 weeks old).
2. Candid conversations: ask the tough questions regarding the application like "does the architecture needs to be changed?" Have all the developers review the current app and see what should be changed. Identify the large parts of the code to change (architecture) and what are the smaller (low hanging fruits) projects that can give more momentum to the project.
3. Go agile! An agile methodology like XP, Scrum, and Kanban add great value to projects specially like pair programming, test-driven development (tdd), domain-driven development (ddd), and continuous integration (CI). The greatest thing about Agile is its rapid time to market. Small iterations means that your customers can see what you did in a couple of weeks and get their feedback. This also provides early risk reduction since you can find bugs relatively quickly. Pair programming helps mentor junior developers and avoid the silo effect. TDD guarantees that any code added to the application is tested before shipping it to production and gives better quality to your customers. DDD adds "depth" to your code and isolates all the business logic in one area of the code. This way, any developer know that if there is a change in the business logic, he/she needs to look for the domain packages. Finally, CI (building pipelines) it is primarily focused on asserting that the code compiles successfully and passes the suit of unit and acceptance tests (including performance and scalability tests).

Legacy code is a dreaded word for developers. The fact is that no developer wants to develop in Java 1.4 or Struts 1.x. If your want a company to attract good talented individuals, try to handle your legacy code.

Again, I'm sure that I missed or don't understand ALL the reasons why so many companies have large legacy code in their core systems, so please...I welcome your thoughts in this matter.

Want to motivate workers? Just ask, "any blocks?"

A manager can make a different when it comes to progress and can control it. As a manager, there are moments when the team makes great strides and everything seems to be humming. These are moments when our constituencies and business owners are happy that we are making progress. Most important, these are the moments when the team is extremely motivated. For over three years, I thought that these moments were out of my control. It all started three years ago when I worked with a team of ThoughtWorks. One of the project manager said,

...when you are a high level manager, you don't make a big difference at work.

Later at a bar we dissected that sentence. When you are a manager, progress is mostly made by people under you, but you are not doing the work per-se. You can measure, forecast, but you really can't increase the speed/velocity of the project.

On December, I read the article What Really Motivates Workes by Teresa M Amabile and Steven J. Krammer on HBR and found out that the top motivator for workers is progress. They based a research purely on understanding the power of progress. The authors found out that

on days when workers have the sense they're making headway in their jobs, or when they receive support that helps them overcome obstacles, their emotions are most positive and their drive to succeed is at its peak.

As a manager the key motivation turns out to be largely within my control. Manager have a large influence over events that facilitate or undermine progress. This enforces the Scrum methodology of having the daily 15-20 minute meetings and asking the three questions:

1. What'd you do yesterday?
2. What you gonna do today?
3. Do you have any blocks?

I have to admit, I always focused on the first two questions. I did pay attention to the "blocks", but I didn't prioritized them as I should've been. I was under the impression that if we finished/burned tasks yesterday, and we were committed to burning some points today, we were making progress. Now, it's the opposite. The authors suggest to

Scrupulously avoid impeding progress by changing goals autocratically, being indecisive, or holding up resources.

I take a great care of dealing with this blockages ASAP. I don't just focus on the blockages. I take a great care to clarify overall goals, ensure that people's effort are properly supported, and reframe from exerting time pressure to intense that minor glitches are perceived as crises rather than learning opportunities. The other item that I need to focus is on cultivating a culture of helpfulness.

I was pretty impressed with this article and I made adequate changes after I read it. After a few weeks, I noticed some pretty good outcomes specially on my junior programmers. Not so much with my senior developers. One of the reasons is "changing context". When one of the junior developer/engineers gets stuck they would jump to ask the questions to the senior developers. As everyone knows, context changing is very expensive. I'm trying to put some type of threshold for the junior developers to ask a question (20-30 minutes). I was also thinking of making some new rules so that the senior developers don't get bother when they are focused on a particular tasks. One of the ideas was using headphones. If someone is wearing headphones that means that he's focusing on some type of task. I'm still trying to figure out how I can make this balance work, but so far it is good to know that I'm on control of it.