Ask HN: Would you walk away from this?
11 comments
I would engage but not assume it will last very long. In fact I would do a three pronged approach early on.
1) I would identify a particularly nasty corner of the code base that could be sectioned off and improved in such a way that everything that touches it will be easier to deal with. This prong is your short-term easy win "we did something to make life better."
2)Develop a reasonably detailed plan for complete update and refactor within .NET environment. This preserves the legacy, skills and domain knowledge of the current staff.
3)Develop a broader plan for a green-field rewrite in a modern environment with great developer tools, training and support.
My guess is that they will not take either of the more radical approaches but you will have delivered consulting on what they can do to speed up their development process. They might not like the implications of the answers and at that point you can probably just walk away.
2)Develop a reasonably detailed plan for complete update and refactor within .NET environment. This preserves the legacy, skills and domain knowledge of the current staff.
3)Develop a broader plan for a green-field rewrite in a modern environment with great developer tools, training and support.
My guess is that they will not take either of the more radical approaches but you will have delivered consulting on what they can do to speed up their development process. They might not like the implications of the answers and at that point you can probably just walk away.
"Consult" can mean a couple different things. Are you working as a contractor just focused on improving the dev workflow? If so, there's not much I can offer you other than to keep beating the drum and trying to get some attention on the issue.
But if you were brought in as a proper "consultant", then you might be in the perfect spot to address this. Companies like this bring in outside experts for one of two reasons: either so they'll say exactly what the person hiring them wants them to say, or so they'll be free of any political ties inside the company and free to say what needs to be said. You'll already know if you're the former.
You need to be the expert they hired you to be. See if you can arrange half-hour interviews from developers on up to the top of the company about the product, how it's developed, how it's sold, etc. Ask how development resources are scheduled. Quantify the time lost to working with the development environment.
Don't ask for permission to do these things. Tell them you'd "like to" or you "need to".
Most importantly, propose solutions. Describe them as "bold" and "visionary" for the upper management. Talk about cost savings in developer time and tools. Talk about the extra time/cost of on-boarding new employees. Show Google trend data and stats from job postings to show their pool of potential employees has moved on to more modern development stacks, and the quality and quantity of new hires is at risk.
Remember, you were brought in to say all those painful things people may actually be thinking but don't feel they can say.
And if you can't get anywhere with anybody, that's your report right there. Go right to the head of the company and say "I can't continue with the work you hired me to do because your employees are not engaged enough or committed enough to change. I was brought in to fix technical problems, but this is cultural".
BE the expert. Be the one who can say all the bad things everybody is thinking and walk out the door with a check at the end.
Edit: also, pay close attention to seren's answer. There are no mustache-twirling villains here, just people trying to do their job day-to-day and not get fired.
But if you were brought in as a proper "consultant", then you might be in the perfect spot to address this. Companies like this bring in outside experts for one of two reasons: either so they'll say exactly what the person hiring them wants them to say, or so they'll be free of any political ties inside the company and free to say what needs to be said. You'll already know if you're the former.
You need to be the expert they hired you to be. See if you can arrange half-hour interviews from developers on up to the top of the company about the product, how it's developed, how it's sold, etc. Ask how development resources are scheduled. Quantify the time lost to working with the development environment.
Don't ask for permission to do these things. Tell them you'd "like to" or you "need to".
Most importantly, propose solutions. Describe them as "bold" and "visionary" for the upper management. Talk about cost savings in developer time and tools. Talk about the extra time/cost of on-boarding new employees. Show Google trend data and stats from job postings to show their pool of potential employees has moved on to more modern development stacks, and the quality and quantity of new hires is at risk.
Remember, you were brought in to say all those painful things people may actually be thinking but don't feel they can say.
And if you can't get anywhere with anybody, that's your report right there. Go right to the head of the company and say "I can't continue with the work you hired me to do because your employees are not engaged enough or committed enough to change. I was brought in to fix technical problems, but this is cultural".
BE the expert. Be the one who can say all the bad things everybody is thinking and walk out the door with a check at the end.
Edit: also, pay close attention to seren's answer. There are no mustache-twirling villains here, just people trying to do their job day-to-day and not get fired.
To take this one step further: You don't have to decide whether to walk away. You just say what they need (not want) to hear. Then you let them decide for you whether you walk away (by how they receive what you say).
*Solid advice from csixty4--
It's a ballsy (smart) play going to the CEO. Assuming this is cultural, he may be very isolated from these issues. Be prepared for that. Ultimately, how they respond will tell you if this is a client worth your time & energy.
It's a ballsy (smart) play going to the CEO. Assuming this is cultural, he may be very isolated from these issues. Be prepared for that. Ultimately, how they respond will tell you if this is a client worth your time & energy.
I'd engage if you're up for a long-term commitment. The good news is: the problems you're experiencing are pretty standard; the bad news is: it's going to be a slightly painful road ahead to crawl out of that hole.
You're not going to be able to fix everything at once, there's going to be some amount of triage necessary, so you've got to prioritize your concerns. Figure out which changes give you the most bang for your buck. If you can prove your value by making a few small strategic changes, leadership might trust you to do bigger overhauls later on.
If it was me, my main concern would be that the engineers don't want to get their hands dirty. That's a really bad sign. Perhaps the biggest change you could implement short-term would be to flip that culture on it's head. Set some team goals around testing-coverage %, and documentation-coverage %. Encourage small teams to pick a small part of the codebase, refactor it, write tests for it, and write documentation for it. Reward them heavily for every little increase in coverage. Make sure they feel pride of ownership. Make sure they know they're not responsible for 13 years of code...just their tiny corner of it. The main goal is to stop the developers from tying their perceived self-worth/value to NEW features; that can lead to a "slap more lipstick on this pig" mentality. You want them to feel like investing time/energy in the current codebase is worth it.
Little by little your metrics will improve. Eventually the codebase will be stable enough (and the team will be productive enough) that you'll be able to say "okay, I want 3-5 developers to split off from the herd and start a ground-up rewrite". And that's where the real fun starts.
You're not going to be able to fix everything at once, there's going to be some amount of triage necessary, so you've got to prioritize your concerns. Figure out which changes give you the most bang for your buck. If you can prove your value by making a few small strategic changes, leadership might trust you to do bigger overhauls later on.
If it was me, my main concern would be that the engineers don't want to get their hands dirty. That's a really bad sign. Perhaps the biggest change you could implement short-term would be to flip that culture on it's head. Set some team goals around testing-coverage %, and documentation-coverage %. Encourage small teams to pick a small part of the codebase, refactor it, write tests for it, and write documentation for it. Reward them heavily for every little increase in coverage. Make sure they feel pride of ownership. Make sure they know they're not responsible for 13 years of code...just their tiny corner of it. The main goal is to stop the developers from tying their perceived self-worth/value to NEW features; that can lead to a "slap more lipstick on this pig" mentality. You want them to feel like investing time/energy in the current codebase is worth it.
Little by little your metrics will improve. Eventually the codebase will be stable enough (and the team will be productive enough) that you'll be able to say "okay, I want 3-5 developers to split off from the herd and start a ground-up rewrite". And that's where the real fun starts.
> Why would a business do this ?
If you are in charge of SW team, without too much SW knowledge, and you have to deliver something in the next 3 to 6 months to you customer, you would likely ask your architect/developers to do "same as previous product" but with a single modification for the new feature. This is the risk-free solution for the short term. Add to that that managers could change every 2 years, there are no incentive to take a big risk in rewriting or upgrading the technology. But this is also the boiling frog syndrome, in the long term you end up with a mess, and if you are in a competitive environment you are getting too slow and your company will be eaten alive. If you are relatively competitor free in your niche market, this could somewhat work...
If you hope to achieve something, you need to have a least one supporter in the upper management. It is still very possible that they are unaware how bad the situation is (or they are but they don't care for the long term). So you're first short term goal, should be to communicate clearly what is wrong, and above all what it costs the company every quarter in term of time lost, bugs, etc. And you should propose an alternate solution with some roadmap (even long term one). "In X years, we will have moved to Z and it will allow us to gain Y"
If you don't have at least one big ally, you'll never manage to have some time or resource to improve the situation. (It will probably be easier to convince some of your colleague).
So if you can't rally any ally in the next 3 months, or at least find potential allies that are aware of the situation, walk away.
PS : Even if this looks ugly, there might have been sound reasons that led to that mess. Every small decision in the past were maybe good for the time being. So don't judge too harshly your predecessors. Especially if you need to convince someone in upper management, that the decision he had taken 5 years ago, was absolutely horrible. (And since you are new, that could a very possible misstep)
Edit : if you have been hired to speed up the dev process, at least someone has started to think that maybe something was wrong, so there is some hope !
If you are in charge of SW team, without too much SW knowledge, and you have to deliver something in the next 3 to 6 months to you customer, you would likely ask your architect/developers to do "same as previous product" but with a single modification for the new feature. This is the risk-free solution for the short term. Add to that that managers could change every 2 years, there are no incentive to take a big risk in rewriting or upgrading the technology. But this is also the boiling frog syndrome, in the long term you end up with a mess, and if you are in a competitive environment you are getting too slow and your company will be eaten alive. If you are relatively competitor free in your niche market, this could somewhat work...
If you hope to achieve something, you need to have a least one supporter in the upper management. It is still very possible that they are unaware how bad the situation is (or they are but they don't care for the long term). So you're first short term goal, should be to communicate clearly what is wrong, and above all what it costs the company every quarter in term of time lost, bugs, etc. And you should propose an alternate solution with some roadmap (even long term one). "In X years, we will have moved to Z and it will allow us to gain Y"
If you don't have at least one big ally, you'll never manage to have some time or resource to improve the situation. (It will probably be easier to convince some of your colleague).
So if you can't rally any ally in the next 3 months, or at least find potential allies that are aware of the situation, walk away.
PS : Even if this looks ugly, there might have been sound reasons that led to that mess. Every small decision in the past were maybe good for the time being. So don't judge too harshly your predecessors. Especially if you need to convince someone in upper management, that the decision he had taken 5 years ago, was absolutely horrible. (And since you are new, that could a very possible misstep)
Edit : if you have been hired to speed up the dev process, at least someone has started to think that maybe something was wrong, so there is some hope !
Can you see a light at the end of the tunnel? Does the business side of the business understand how much technical debt has arisen? Is there a third party solution that does 90% of what you need? Does the business need to keep upgrading the app or can it end of life it? Are there subsystems you can upgrade relatively easily that will have business benefit?
"Where there is muck, there is brass."
I would get all your concerns on the table with the person who writes checks and present some alternatives and let them choose.
(I went through this a few years ago with a 11 year old java + gwt webapp and had some success.)
"Where there is muck, there is brass."
I would get all your concerns on the table with the person who writes checks and present some alternatives and let them choose.
(I went through this a few years ago with a 11 year old java + gwt webapp and had some success.)
[deleted]
I would absolutely engage...IF the senior management is committed to changing the status quo and is ready to invest money and time into the effort and is ready to make changes (including org changes) to make this effort happen. I have been in countless situations like these and the only times I have seen success is when the executive team is committed.
Also, don't expect anything drastic to change in 3 or even 6 months. 10-13 years old is a lot of time and the technical debt would probably be huge. If I have to guess, you are probably looking at a multi-year multi-project effort.
Also, don't expect anything drastic to change in 3 or even 6 months. 10-13 years old is a lot of time and the technical debt would probably be huge. If I have to guess, you are probably looking at a multi-year multi-project effort.
1) Are they paying enough? Money is not the only motivation, but usually a underplayed employment comes with other environment problems.
2) Some ideas that may be useful: "Getting Things Done When You're Only a Grunt" http://www.joelonsoftware.com/articles/fog0000000332.html
2) Some ideas that may be useful: "Getting Things Done When You're Only a Grunt" http://www.joelonsoftware.com/articles/fog0000000332.html
This seems like an awesome and career defining movement to overcome a worse case scenario challenge.
Today the application which in the end of it all is a web application, consists of a lot of old ASP classic code, a COM+ bridge for being able to function within a mix of a lot of different .NET libraries written in .NET 3.5 (CLR 2). COM+ acts as a bridge between the two technologies.
The teams cannot compile code inside the development tools, it can't debug unless they do it with some obscure hacks and workarounds and it seems that no one is really in control of what is going on in the core code base and no one really want to touch the original code base to clean it up and refactor/re-write it.
My concerns are really rooted in different aspects of the project.
The project has been like this for multiple years, i mean, the ASP code base is around 10-13 years old. There is nothing wrong with old technology I think but building on top of it for over 10 years was probably not a great idea.
Then someone has tried to build a gap between ASP and ASP.NET and I assume this is because of business-needs and also no one really wanting to get their hands dirty with a refactoring.
Why would a business do this ? Keep patching and re-patching old code instead of cleaning up and making things smoother and safer.
Not to talk about the effeciency of developers and teams.
I am frustrated, only 3 weeks in, and I am obviously not the only on whom has tried to figure this out, but everyone has just given up and said "this is just how it is.".
Given those facts, would you engage or walk away ?
I just don't like to walk away, but this is basically a big mess which in turn runs a multi million dollars business.