3 ms·

I sorta disagree. Sometimes being CTO is about instituting technical leadership from scratch. There have been a couple times where i've worked with a company (a

by imajes 16y ago

I sorta disagree. Sometimes being CTO is about instituting technical leadership from scratch. There have been a couple times where i've worked with a company (as a contractor) and helped them in a CTO role. This has ended up with a need to scrap everything and start again. That decision was acceptable because of the complete lack of any technical experience in house (100% outsourced, multiple vendors) who had very different patterns of development. Couple this with no tests, no process and no patterns, you're stuck trying to work against something that's unpredictable. The way forward then is to hire a team (even if it's just one guy) internally who can have ownership of code. Then instituting good practice and a sensible method of rebuild and rediscovery. Obviously this hinges on having enough runway to get into it properly. tl;dr: sometimes it's ok to scrap it all and start again when your goal isn't about preserving code but instead is about building a better product and technical culture inside a company. Getting downvotes - I wanted to add something: There's a real risk of making problems worse when you don't have any ability to stop and change. Working with existing code is great but when you have existing customers running into bugs on a daily basis, and fixing them would change the business logic that others are relying on, you either choose to build more technical debt or you swallow it and start again. Obviously this depends on runway, position, etc. There are many times when companies go through their proto and raise seed only to find that their original hypotheses aren't working, and to change requires a significant re-architecture. Bolting this on to existing codebases can end up with code so complex that it won't stay up, and you end up spending six months in pure fire-fighting ops mode to keep the thing alive. Knowing when to recognize this and acting accordingly is the right approach, even if that sometimes means calling it a day on the existing code and starting again.

auxbuss 16y ago
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.
- imajes 16y ago
  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).
- variety 16y ago
  "rewriting systems" != "stopping the train" (if done properly).
- fdagggee 16y ago
  There are lots of reasons that technological assets can be very poorly aligned with a company's current goals. In those situations, a redesign is often warranted. I've often seen it occur as a confluence of: bad hires, poorly managed projects, companies that change direction, and availability of better solutions to the same problems. Just because something can be done, doesn't mean it's the best use of resources. CTOs are responsible for making intelligent fix/replace decisions, and it really doesn't sound like you're advocating that at all. Rather, it sounds like you're advocating an ignorant 'only fix' position.
- j_baker 16y ago
  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.

by imajes 16y ago

auxbuss 16y ago

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.

imajes 16y ago
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).
variety 16y ago
"rewriting systems" != "stopping the train" (if done properly).
fdagggee 16y ago
There are lots of reasons that technological assets can be very poorly aligned with a company's current goals. In those situations, a redesign is often warranted. I've often seen it occur as a confluence of: bad hires, poorly managed projects, companies that change direction, and availability of better solutions to the same problems. Just because something can be done, doesn't mean it's the best use of resources. CTOs are responsible for making intelligent fix/replace decisions, and it really doesn't sound like you're advocating that at all. Rather, it sounds like you're advocating an ignorant 'only fix' position.
j_baker 16y ago
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.