Comment by thrwwyngnr | Hacker News Reader

Comment by thrwwyngnr | Hacker News Reader

Parent Full thread

> Are your founders / leaders Engineers?

Actually, yes. They wrote the software that is currently used in production.

But they don't want to touch engineering with a ten-feet pole. One time they complained that engineering was taking too long to finish stuff and engineering demanded an apology.

> Why do team members think that you're moving too-slow / too-fast?

Good question. Both sides provide very good arguments, but they're super polarized.

Half the team is the MVP-lean-startup-crowd and is constantly complaining that the code is too complex, with too many abstractions and it is and hard to test and debug. They claim they want to push simpler code that works and optimize/refactor as needed, but that never flies on code reviews. They claim that the constant refactoring (I swear I hear that word ten times a day) are causing way too many bugs.

The other half comes from an enterprise background and complains that the code is currently too messy and unsafe, and claim they need to refactor weird parts before doing pretty much any feature. They believe in making bigger deliveries instead of incremental ones, and point to bugs caused by the other team as proof that they need more time to get it right.

For obvious reasons, management has ALWAYS sided with group number one, which caused a lot of problems and accusations of favoritism.

My hot take? Yeah, three years is way too long for a simple web app from a startup to be ready.

Whoever is in control of this team, needs to pick one, and stick with it. Hiring enterprise developers if you really want your MVP out the door yesterday is asking for trouble.

It also leads me to believe your product currently has a dearth of tests. Most of the bugs that are generated from refactoring should be caught by automated tests. Until you have tests, you shouldn’t refactor (always write a test first).

If your product is too difficult to test, the enterprise crowd may have a point and the initial (and further) architectural decisions have been wrong, and this suggests a lack of senior engineers.

Last point, if your abstractions are making it more difficult to test, then the abstractions are almost certainly wrong.

> Hiring enterprise developers if you really want your MVP out the door yesterday is asking for trouble.

You're right, this is something I'll talk with HR about. I realize we're not hiring consistently and that might be causing problems.

>> Are your founders / leaders Engineers?

> Actually, yes. They wrote the software that is currently used in production.

> But they don't want to touch engineering with a ten-feet pole. One time they complained that engineering was taking too long to finish stuff and engineering demanded an apology.

Engineers can get very touchy about code they write. It's kind of their baby. It sounds like the highest levels of management have written what is being run, and yet not want to seem to maintain it, or directly lead the engineering org. Then they also want a great engineering team to improve what they've been doing, which inevitably ends up being ways that the initial implementation could have been done better. Sounds like a double bind for the employees. If an employee finds a much better way of doing things, the founders should be happy, but they may be sending mixed signals.

Another example is that when you've written a bunch of code, you are the expert. Anyone else working on it will be going slower, because they don't have the background that the initial author did.

If there are two sides, and one says that the code is too complex, and the other side says it's messy and unsafe I'm likely to believe both of them. For different parts of the code, you may need incremental improvement, or you may need to rewrite it. This is where you need real engineering leadership.

> It sounds like the highest levels of management have written what is being run, and yet not want to seem to maintain it, or directly lead the engineering org.

Well, in their defense: they have to, you know... run the company.

Engineering was supposed to maintain the current software, but they (engineering) chose to deprecate it and make a new version from scratch. It is just taking way longer than expected, three years and just a fraction of the original functionality.

> If an employee finds a much better way of doing things, the founders should be happy, but they may be sending mixed signals.

Problem is: they're not doing anything better. Customers prefer the old software. Other employees prefer the old software. Even some people on the team prefer the old software.

Engineering was supposed to maintain the current software, but they (engineering) chose to deprecate it and make a new version from scratch. It is just taking way longer than expected, three years and just a fraction of the original functionality.

This seems like a key issue. It's time to evaluate progress on the re-write and work out what to do next, with all options on the table (including re-focussing on the old software, or even starting afresh with a "version 3").

Are there any people in the engineering group who have been doing non-trivial bits of work on the old software? It may be worth cultivating these people and taking their opinions seriously, even if it ends up putting other (perhaps more senior) noses out of joint within the engineering group.

One of the guys who left engineering takes care of the old software, plus some other new stuff.

He's indeed friendlier than engineering.

Might be a good idea indeed to integrate him with his old team, or maybe build a new team around him.

Make sure you understand why this person left engineering. "Integrating him with his old team" could be good, but could also be throwing him right back into the middle of something he was actively trying to get away from.

Right, I get that they have to lead the company. But if other parts of the company are doing well, and engineering is struggling, and they have key insights into how the software was built, and why it was better, it would seem they would be in the perfect spot to lead the engineering team to a better place. They are the subject matter experts, and it seems like this app, whatever it is, is key to your business. And they previously made it successful. But you said they don't want to touch it with a 10-ft pole. This just doesn't add up.

They tried once, but that was a year ago.

You're have a good point. Maybe after one year things will be different.

Reply on news.ycombinator.com