Hacker News Reader

Comment by tom_b | Hacker News Reader

FTA (favorite part for me)

Most time isn't spent programming anyway - programmer time is spent:

    a) fixing broken stuff that should not be broken
    b) trying to figure out what problem the customer actually wants solving
    c) writing experimental code to test some idea
    d) googling for some obscure fact that is needed to solve a) or b)
    e) writing and testing production code

e) is actually pretty easy once a) - d) are fixed. But most measurements of productivity only measure lines of code in e) and man hours.

For me, b) is a bottleneck. c) is far and away my favorite part. Nothing like green-fielding . . .

View on HN

That's the core of why outsourcing coding and fixed price projects so often fails - it's overestimating the role of (e), underestimating the difficulty of (a)-(d), and discounting the communication friction when (a)-(d) and (e) is not done by the same person.

I had a paid internship in college, many years ago, where I basically spent three months twiddling my thumbs waiting for a project, and when I finally got one, it was creating an MS Access database to count SLOCs. If they were that concerned with productivity, perhaps they could have given me something useful to do.

At least at the larger software companies do they really only measure LOC and man hours? It seems like you could develop decent estimates if you tracked every asset on a job, its performance, and the overall conditions of the job itself.

The problem is that the assets are dynamic. If you give me a single complete requirement for some little feature I can give you a pretty accurate estimate. But most of my requirements are things like "Write an app to do X." The only part of that I can estimate is the part I've done before, but if the app were just like all the apps that came before there would be no need for a new app. But the juicy candy center is an abject mystery and there is nothing to compare it to from which to derive an accurate estimate. Once you've dug halfway into it, you'll be tossing out new requirements. Maybe you can make good estimates on those, but your a priori estimate is now probably really off.

For me there is another time-consuming step:

c') tooling: learning/debugging the latest test tool, test runner, deploy tool, source management system, CI system, etc. etc.

Indeed, now there are so many tools that you can't just expect a reasonably experienced programmer to just know the tools that you're using.

You have to either:

a. stick to old and/or boring and/or obviously inferior tools and programming languages, or

b. expect to pay the price of the time lost by programmers joining your team to learn the tools that you have chose or "worse", to actually survey all the options and pick the best tools for the project

...I know, the evolution of technology needs diversity in everything, including tools, so that some form of "selection" can actually push forward the best alternatives, but just as in nature and biology, "evolution" has huge prices to pay (in biology the most tragic prices are mortality and cancer, in software engineering I don't know what their analogues are, but I dread to think that we're already close to facing these "prices"...).

Indeed, now there are so many tools that you can't just expect a reasonably experienced programmer to just know the tools that you're using.

I can think of at least two further difficulties that come with the explosion of available tools:

1. It’s hard to know whether a tool is actually worth using at all. Many tools sound appealing because you’re familiar with the problem they aim to solve but not yet familiar with all the quirks and edge cases and hidden costs of using the tool instead.

2. Many tools look promising in their early days, when they are prime examples of enthusiasm driven development. It’s another thing to ask whether the tool is still going to be in active development five years down the line, when there are newer and shinier things to work on. Even if there are, your 100,000 line code base might still need that security fix or one of the 10% of missing features that were on the roadmap when you first started integration.

I’m all for using the right tool for each job, and I’m certainly in favour of using good tools rather than doing everything the hard way, but figuring out which tools those are gets harder as tools proliferate.

I'm feeling this way about JavaScript now. So much so I almost don't want to use JavaScript at all. There are so many JS frameworks and libraries right now; they can't possibly all survive but who knows which ones will?

True, this is why I prefer old tried and true languages and tools, as much as I'd love to live on the bleeding edge. The day is just too short to use CoffeeScript/Dart/Haxe when there's JavaScript. Completing projects that seem "easy" is hard enough to begin with.

Reply on news.ycombinator.com