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

21–29 of 29 posts

Re: What it really means to be a CTO

#21

Post by [deleted] »

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…

[deleted]

Re: What it really means to be a CTO

#22

Post by megrimlock »

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…

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

Yes! This broad view is what separates our tech leads from the brilliant individual contributors. They are the folks who instinctively reach for broader context in every engineering tradeoff they make, instead of seeing the code as an end unto itself.

Re: What it really means to be a CTO

#23

Post by sz »

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…

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

Look at Windows Phone 7.

Re: What it really means to be a CTO

#24

Post by elliottcarlson »

I was brought in to a company a while back and took on the leadership role for a while (then brought in a friend to actually be the CTO as I wanted to be pure hands-on). When I arrived at the company, the original code base was a mess - originally outsourced to India, then given to a company in China and then a developer in the Czech Republic. The code was using amazing code like "$sourceboy = $sourceboy;" and tons of other gems.

Anyhow, the decision was quite clear a rewrite was in order. The original code base received a little love here and there to make it work, but in the end we replaced it all and the company ended up selling for a little shy of 8 digits.

While you may not be able to just scrap it all, there is no reason you can't do things the right way behind the scenes and then relaunch the right way over time. I think a good CTO or leader should recognize what will be better for the company, and perhaps at times that does indeed involve maintaining what you have - but if it is indeed broke; it's also in your best interest (as well as the company's) to fix it.

Re: What it really means to be a CTO

#25

Post by DanielRibeiro »

The point it makes is one aspect that Mike Cohn's chapter on Financial Prioritization really gives great insight (http://my.safaribooksonline.com/9780137126347/ch10). In the end, such issues are a business decision, and making it can be very detailed and complex or very concise and simple, depending on things like project size and how agile must you be. But they are business ones. Looking into them through any other lens risks a series of possibly very bad decisions.

Re: What it really means to be a CTO

#26

Post by rickmb »

The role of the CTO depends on the context. Sometimes you lead, sometimes you just facilitate. Sometimes you focus on technical quality, sometimes you focus on business objectives. It all depends on the balance within the company and the companies objectives.

Bottom line is that you base your strategy on what the company needs, not on some abstract notion of a good CTO. The only consistent objective is to make yourself as superfluous as possible by creating a balance between engineering quality and business objectives that maintains itself without constant management interference.

Re: What it really means to be a CTO

#27

Post by danshapiro »

cookiecaper wrote: post #14
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.

That's me. Scott asked me to do a guest post and had no idea what I'd come up with. I'd been telling folks this story about him for a while, so I figured it was as good an excuse as any to share it with a wider audience.

Re: What it really means to be a CTO

#28

Post by edanm »

variety wrote: post #11
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 techn…

I'm not sure about that.

What I took away from the article is this: whenever you're thinking of rewriting from scratch, there's a better way - incrementally replacing the code. It's not as fun, and it feels worse, but it ends up with much better code. I'm pretty sure this is nearly always true.

Joel outlines the reasons, but the most important one, imo, is this: you're not going to do a better job. You think you are, because you see that the code is a mess and think you're better than the people who designed it. And you're probably right (or at least, you know more.) But a system that has years of work on it is not something you can whip up again from scratch - you're going to miss all the same things they missed the first time, when they were designing it, and either recreate all the bugs, or make your new system a mess.

Incremental improving is nearly always the saner solution.

Re: What it really means to be a CTO

#29

Post by ulrich »

edanm wrote: post #28
variety wrote: post #11

Earlier quoted context omitted.

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

I'm not sure about that. What I took away from the article is this: whenever you're thinking of rewriting from scratch, there's a better way - incrementally replacing the code. It's not as fun, and it feels worse, but it ends up with much better code. I'm pretty sure this is nearly always true. Joel outlines the reasons, but the most important one, imo, is this: you're not going to do a better job. You think you are,…

I second that. It's not the "rewrite" that is bad, but the "rewrite from scratch". You might end up with a completely different codebase if you do it incrementally.
Post reply on HN