Hacker News Reader

Comment by auxbuss | Hacker News Reader

I'm calling bs on this.

You have to keep the train moving. That keeps the cash coming in. You can't stop the train.

So, you have to take what you have and somehow -- that's what you are being paid for and hopefully you have the chops -- manoeuvre the beast into a better state. This is fscking hard, especially when you have to get the darn thing under test. And it's invariably massively undervalued by most biz management teams.

You can _always_ extract value from operative but shitty code, even if you have to stick your head around the U-bend and pull it back with your teeth. If you don't know that yet, then you've more to learn.

View on HN

I don't know. When you're trying to build a team in a market where there are more jobs than qualified applicants, telling them that you have to 'rescue' an app is a turn off and won't get you anywhere.

Also, when the real value within the app is a simple product, breaking it out and re-engineering based on what you've learnt takes about roughly the same time as it does to walk through the code line-by-line and add in valuable tests.

Refactoring legacy code by multiple vendors is always a risky proposition (and much much harder to sell to clients who want a deadline for delivery).

Personally, I see the CTO's job as being the one to advocate pristine, perfect code at the expense of business objectives. The reason is simple: if they don't, nobody else will. Of course the business side of the organization is always going to be pushing for more features at the expense of code quality. Why? Well, they're not the ones who will take the blame for code sucking.

If you give in to them too many times and end up with buggy code where trivial changes take a month, but has all the features that are needed where do you think the blame will fall? I can guarantee you it isn't going to be the business side.

The goal shouldn't be for the CTO to be the business side's technical henchman. It should be to look after the technical side of things. If a rewrite is the best decision technically (without considering the business), then that's what the CTO should advocate, but they need to be willing to work with the business side to find a solution that works for both sides.

The CTO needs to be part of the executive team, so they don't have the luxury of ignoring the business objectives. The CTO should be able to make a business case for investing in quality engineering. Quality engineering has benefits for the business, but they are not always worth the price.

Engineers are the only ones who can advocate for pristine code without tradeoffs, and I would argue that great engineers care enough about the business to not do that. Really great engineers just build the pristine code in the same amount of time regular engineers would have taken to get a simple version almost-working.

I actually like the idea of "technical henchman", though!

Really great engineers just build the pristine code in the same amount of time regular engineers would have taken to get a simple version almost-working.

This has been key in my experience. I'll build a feature that is flexible, clean, well factored, and completely documented in the same time it requires someone else to make a half working mess.

CTO's as I'd like to understand them bring the bar as high as they can within business constraints. Doing any less is accepting mediocrity. Is that something you'd want in an executive leadership role?

"rewriting systems" != "stopping the train" (if done properly).

Sure you can extract _some_ value but is the tradeoff always worth it?

Look at Windows Phone 7.

Reply on news.ycombinator.com