Should you code well or code fast? • Hacker News Board

Re: Should you code well or code fast?

#21

Post by davesims » Fri, Dec 13, 2013, 3:31 PM UTC

Been thinking about this a lot lately, and I think one of the problems is the language and metaphors we use to describe the quality of the code.

Words like 'clean', 'elegant', 'well-structured', even SOLID are qualities of objects we want to consider at a distance, like statues or paintings. They are words of repose and reflection. You know: business death.

Here's an example from this essay:

"There is a reason good code is considered to be a form of poetry. It's elegant, clean, easy to read, and fun to write. These are all exceptional qualities that we should strive for every single day."

Try telling a product manager or CEO or other stakeholder how 'clean', 'easy to read', or -- God forbid -- "fun!" your code is, and watch their eyes roll back in their head. (I exaggerate for effect.)

These ideas make sense to us as developers because that's what we spend our entire day doing: considering, reflecting and thinking about code. But I think what we should be talking about is the inherent speed of the codebase. I'm not talking about my velocity as a developer, or the velocity of the team and how many story points they deliver per sprint, but the inherent velocity of the codebase as a function of its technical debt. Codebases, from a business standpoint, should not be "clean" or "dirty", but rather "fast" or "slow".

Technical debt should be surfaced to the stakeholders using language that conveys the dollar value, the fiscal liability, of technical debt. The most accurate way to describe that and show how debt is slowing your team down, is to talk about its inherent speed.

"Our codebase is getting slower" makes business sense to a Product Manager. "Refactoring this will make our codebase faster" is a phrase that conveys the worth of initiatives that otherwise seem to have no immediate effect on the bottom line.

All of the tools and agile methods we have talk about velocity in terms of what a team is delivering, and can parse that down to the sprint and developer level. But in my experience, the most significant contributor to a team's relative speed is the (intertia|speed|velocity|momentum) of the codebase itself, as a function of its technical debt. I think we need to start using language that intuitively and constantly surfaces the dollar value of technical debt to the stakeholders, so that "just ship it!" no longer sounds like a sound business strategy.

Re: Should you code well or code fast?

#22

Post by alexrson » Fri, Dec 13, 2013, 3:41 PM UTC

My favorite pithy insight on this subject is from McConnel's code complete (mangled, most likely):

"Code is usually read more times than it is written."

Re: Should you code well or code fast?

#23

Post by collyw » Fri, Dec 13, 2013, 4:46 PM UTC

mathattack wrote: post #18

redact207 wrote: post #2

Answer: learn to do it the right way and you'll end up coding faster.

I was thinking similar. The best (and deepest thinking) programmers that I know are also the fastest. They don't always work the most hours or seem the most harried (which doesn't bode well for places like Advertising which like to seem "Busy and Creative") but they can produce in 20 lines in a day what others produce in 500 lines in a week. They may not look as fast though. ("What? All day? Just 20 lines?")

I also notice that good design decisions can go a long way. I implemented a "shopping cart" type feature where users can select a set of samples they are working with. Initially it was just to compare ones which would have been paginated apart on the interface, and there would have probably been a quicker fix. But it has proved useful for many other features since then.

Re: Should you code well or code fast?

#24

Post by jdlshore » Fri, Dec 13, 2013, 5:54 PM UTC

davesims wrote: post #21

Been thinking about this a lot lately, and I think one of the problems is the language and metaphors we use to describe the quality of the code. Words like 'clean', 'elegant', 'well-structured', even SOLID are qualities of objects we want to consider at a distance, like statues or paintings. They are words of repose and reflection. You know: business death. Here's an example from this essay: "There is a reason good c…

"Codebases, from a busines standpoint, should not be 'clean' or 'dirty', but rather 'fast' or 'slow'."

This is pure brilliance. I can't express how much I love this idea.

Re: Should you code well or code fast?

#25

Post by davesims » Fri, Dec 13, 2013, 6:15 PM UTC

jdlshore wrote: post #24

davesims wrote: post #21

Been thinking about this a lot lately, and I think one of the problems is the language and metaphors we use to describe the quality of the code. Words like 'clean', 'elegant', 'well-structured', even SOLID are qualities of objects we want to consider at a distance, like statues or paintings. They are words of repose and reflection. You know: business death. Here's an example from this essay: "There is a reason good c…

"Codebases, from a busines standpoint, should not be 'clean' or 'dirty', but rather 'fast' or 'slow'." This is pure brilliance. I can't express how much I love this idea.

Thanks! The more I think in this direction the more I think we need to really push this language or something like it. As much as I love the idea of 'craftsmanship', etc., when business stakeholders hear that language and similar ideas, fear grips their heart. We can do a better job creating awareness of the dollar value of bad code by changing the way we describe it in a credible way.

Re: Should you code well or code fast?

#26

Post by wafuru » Fri, Dec 13, 2013, 6:31 PM UTC

cpncrunch wrote: post #19

wafuru wrote: post #9

The best developers I know have the experience to know when each is required. Getting the right balance between speed and quality is one of the things I find hugely valuable in a developer, usually more so than their maximum coding speed or maximum output quality.

The best developers code well AND fast in my opinion.

When pushed to their limit, one of the two will drop first.

Re: Should you code well or code fast?

#27

Post by davesims » Fri, Dec 13, 2013, 6:55 PM UTC

jdlshore wrote: post #5

This wasn't a very good essay. The closing line sums up its problem: "We need to complete quality work in the shortest amount of time possible." Why, yes, I would like a double helping of pablum! Thank you for offering. You know, before now, I thought it was best to complete quality work in the longest time possible. Sarcasm aside, the most telling line was this one: "If the project is for a three-month campaign that…

"Code quality matters when you have a team of people developing and maintaining software over a long period."

And for me, 'a long period' is anything longer than a month, or more specifically, the time period it takes for me to have to change any code I've already written in order to deliver new business value to a customer.

...and just noticed your 'six weeks' estimate. We're on the same page here it seems. :)

Re: Should you code well or code fast?

#28

Post by lifexkills » Fri, Dec 13, 2013, 7:48 PM UTC

davesims wrote: post #21

Been thinking about this a lot lately, and I think one of the problems is the language and metaphors we use to describe the quality of the code. Words like 'clean', 'elegant', 'well-structured', even SOLID are qualities of objects we want to consider at a distance, like statues or paintings. They are words of repose and reflection. You know: business death. Here's an example from this essay: "There is a reason good c…

This is a great idea. Thanks for sharing.

It's definitely much easier to convince people when you're talking dollars rather than "beauty" or "maintainability" which are much more abstract concepts. This pushes that to the forefront.

I wonder if anyone has experience with trying to use this language that they can share. I'm curious because it seems like a great idea. But I wonder if it would solve the "just ship it!" mentality. I still feel like there may be a missing component which is that what might be fast to build now will slow down the overall development effort later on. I think that time gap is one of the big things that stakeholders fail to think about. They're thinking "what can we get out the door now?" and not further down to what impact that will have on getting other things out the door a few months from now.

Great post!

Re: Should you code well or code fast?

#29

Post by davesims » Fri, Dec 13, 2013, 8:14 PM UTC

lifexkills wrote: post #28

davesims wrote: post #21

Been thinking about this a lot lately, and I think one of the problems is the language and metaphors we use to describe the quality of the code. Words like 'clean', 'elegant', 'well-structured', even SOLID are qualities of objects we want to consider at a distance, like statues or paintings. They are words of repose and reflection. You know: business death. Here's an example from this essay: "There is a reason good c…

This is a great idea. Thanks for sharing. It's definitely much easier to convince people when you're talking dollars rather than "beauty" or "maintainability" which are much more abstract concepts. This pushes that to the forefront. I wonder if anyone has experience with trying to use this language that they can share. I'm curious because it seems like a great idea. But I wonder if it would solve the "just ship it!"…

Yeah I'm trying to get my head into how this would come about. It would be along the lines of how agile thought leaders shifted the notion of 'man hours' to 'story points', or how we stopped measuring LOC as a feature of productivity.

But there would have to be some cultural and language support for an entire idea around what a codebase is. The idea that it is an object that can possess the property of velocity will take a bit of enculturation. But the software/agile community has done it before, so...