Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What it really means to be a CTO

scottporad.com

Post reply on HN
Print view View original

11–20 of 29 posts

Re: What it really means to be a CTO

#11

Post by variety »

brianwillis wrote: post #8

This reminds me of Joel Spolsky's Things You Should Never Do ( http://www.joelonsoftware.com/articles/fog0000000069.html ). It's old advice, but still as relevant as ever.

It's relevant, but he didn't really mean it to be taken at face value. Because of course it just isn't true (even though people keep repeating it a lot, for some reason).

The world is full of tons and tons of successful, large-scale software systems (from apps to languages to databases to OSs) that were not only "rewrites" of older systems, but had to be written because the original system had incurred too much technical debt.

So what Joel really meant, deep down inside, was "okay it's not that you should never replace large systems from scratch; it's just that you should be very circumspect about it, OK? You don't just go knee-jerkedly ripping out the old stuff just because it's a ugly, a pain to deal with, unsexy, etc. You have to look at the whole picture, and understand the (true) business costs of what you're doing. That's all I'm saying."

Re: What it really means to be a CTO

#12

Post by variety »

auxbuss wrote: post #6
imajes wrote: post #4

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 di…

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 managem…

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

Re: What it really means to be a CTO

#13

Post by fdagggee »

auxbuss wrote: post #6
imajes wrote: post #4

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 di…

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 managem…

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.

Re: What it really means to be a CTO

#14

Post by cookiecaper »

dansingerman wrote: post #7

"one of Seattle’s most impressive companies, I Can Has Cheezburger? " - Really? Does that say more about Seattle, or the Web at large? (Or was this just a joke and I missed the point?)

I found it kind of weird that the guest post on this guy's blog was his friend talking about how great the blog's owner is.

Re: What it really means to be a CTO

#15

Post by j_baker »

auxbuss wrote: post #6
imajes wrote: post #4

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 di…

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 managem…

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.

Re: What it really means to be a CTO

#17

Post by babar »

j_baker wrote: post #15
auxbuss wrote: post #6

Earlier quoted context omitted.

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 managem…

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 an…

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!

Re: What it really means to be a CTO

#18

Post by alttab »

babar wrote: post #17
j_baker wrote: post #15

Earlier quoted context omitted.

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 an…

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 en…

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?

Re: What it really means to be a CTO

#19

Post by johngalt »

This reminds me of "you go to war with the army you have, not the one you want".

It's easy to think about what the perfect greenfield solution would be, but this is rarely the case. There's the "best" solution, and the "most applicable" solution.

In my conversations with non-technical managers I spend much more time arguing against the "best" solution, and for what best fits our situation. If I can't reach them I will break out this line:

"Nothing would make me happier than to spend more money and time on new technology, but I think we can meet your needs with X."

Re: What it really means to be a CTO

#20

Post by melvinram »

A lot of comments here seem to be missing what the post was intending to communicate (IMO.)

It's not about whether starting from scratch is okay or not. It's not about whether mixing various technologies to get to something that works is okay or not.

It's about aligning business needs with the execution plan and the resources available.

Post reply on HN