Comment by emilburzo | Hacker News Reader

Comment by emilburzo | Hacker News Reader

Parent Full thread

>> One of the problems caused by the non-understanding software manager is that he thinks that his subordinates have to produce code: they have to solve problems, and in order to do so, they have to use code. To this very day we have organizations that measure "programmer productivity" by the "number of lines of code produced per month"; this number can, indeed, be counted, but they are booking it on the wrong side of the ledger, for we should talk about "the number of lines of code spent".

Amazing how we still haven't figured this one out yet.

>> I know of one —very successful— software firm in which it is a rule of the house that for a one-year project coding is not allowed to start before the ninth month! In this organization they know that the eventual code is no more than the deposit of your understanding.

It's so hard for me to imagine that such a software firm could actually exist.

Even though I've noticed the advantages of thinking first and coding later on a personal project done in a more relaxed period, I guess it's just too hard to justify your cost without having deliverables (code commits, in this case).

> for a one-year project coding is not allowed to start before the ninth month!

Early in his career Dijkstra had to write an operating system for a machine that had not yet been built. So he wrote the whole thing on paper, working only from the spec. When the machine arrived, his OS pretty much worked. This experience shaped his view of programming for the rest of his life. He came of age when you had to write programs where there was no machine (or you couldn't often get to the machine). That's not a typical situation now - Dijkstra was the very first programmer in Holland. (He later met a group faced with a similar delayed delivery that had not begun work -- he was amazed to hear that they were "waiting for the machine".)

> for a one-year project coding is not allowed to start before the ninth month!

And here we are, asking team leads why development cannot begin till week 2 of a 24-week project.

It is a really strange and funny industry we are in.

I suspect managers and programmers might be counting the weeks from different points in time...

I think at the level of complexity of current day products, the "think for the first 75% of the time" is flat out impossible. Certainly some of the complexity is incidental, but much of it is necessary for the sort of product we have today.

  I think at the level of complexity of current day products, the "think for
  the first 75% of the time" is flat out impossible.

Maybe, but from my experience we don’t do enough up-front thinking. Indeed, if our products are more complex these days then shouldn’t we be doing more thinking? If our products are more complex then diving straight into code is one of the worst decisions we could make. No wonder we end up with tangled balls of yarn.

> Amazing how we still haven't figured this one out yet.

Because humans tend to gain scientific knowledge much faster than they learn from their social mistakes. Managers deal with human relationships, but they really can't apply scientific knowledge to social knowledge.

> I guess it's just too hard to justify your cost without having deliverables (code commits, in this case).

Some domain might do, where the expectations or the competition are very high: military, security, console programming.

This sounds like the waterfall approach taken to an extreme. (Although, even within the waterfall, having time to iterate your requirements a few times, and then your design a few times, would be a good thing...)

Reply on news.ycombinator.com