Comment by ffn | Hacker News Reader

Comment by ffn | Hacker News Reader

I like how the first three or so anti-patterns are in the exact opposite direction as the last three or so. The art of being a programmer is literally "don't waste time over-thinking things, but also don't ship under-thought trash". For all our fixation on simplistic and ease of use, programming is actually incredibly difficult and way more art than science.

And it's exactly this requirement of masterful manipulation of balance that makes me love this field so much and long to get better at it. Getting a handle on the artsy spirit of programming is really what separates the wheat from the chaff in terms of programmer skill. There is no formal programmer guild in real life, but if there was, and there was some sort of test a journey-man programmer must undergo in order to become a master programmer, it would be the test of being given a large project and then deciding correctly exactly how much technical debt to take on to be able to ship a product within a reasonable time-frame and yet have its internals not be complete unmanageable spaghetti.

> I like how the first three or so anti-patterns are in the exact opposite direction as the last three or so.

These are really just proverbs, and it is not unusual to find pairs of proverbs with opposite intent - e.g. http://www.wolaver.org/WordPlay/OppositeProverbs.htm

They have some use as starting-points for discussion, but identifying when one (or which of a complementary pair) is appropriate requires good judgement, and the people who get dogmatic over these things are missing the point.

I think the fact that these sorts of argument feature so much in the discussion of software design and development indicates that there is some way to go before it becomes a fully-mature technical / engineering discipline.

"These are really just proverbs, and it is not unusual to find pairs of proverbs with opposite intent"

Or, taken to the limit, "Moderation in all things, even moderation."

(It may take a moment's thought to see how I got from here to there.)

It reminds me of the quip: "I can deliver your project quickly, cheaply and of good quality - pick two". That said, in my experience, clients tend to see software quality as the least important attribute of the three.

I always tell them, "You can have what you want quickly or you can have what you want cheaply, if you insist on both, you won't be getting what you want."

The cheaply part puzzles me. If it takes X hours to build something, it doesn't matter if you work D hours per day for X/D days, or D/2 hours per day for 2X/D days -- it's the same amount of hours, therefore the same amount of money. The client will pay less per day, but the same amount overall. You could charge on a curve, i.e. 8hrs/day is X, but 10hrs/day is 2X, but we all know overtime doesn't work in the long run.

It seems to me, that that saying works for only the small set of tasks that can be worked on in consistent overtime. Can someone clarify?

you can cut corners by never refactoring and not thinking the design through thoroughly. In the long run this will actually cost you time but in the short run the customer gets something sooner. The problem is that the customer is usually unaware of the looming debt they are accumulating unless an engineer takes the time to explain it to them.

The cost, time and scope trade-off - [http://4.bp.blogspot.com/_bInnDDjGM24/SlVMRBtEOEI/AAAAAAAAFu...]

I'm usually a little meaner and tell people to pick 1.7 of the above.

>clients tend to see software quality as the least important attribute of the three.

It's the one attribute they can't see.

It's the one attribute they can't see immediately. But they will see it eventually. When fixing critical bugs take months and their customers are breathing down their necks they will see software quality at work. It's our job to educate them about these risks since they have a delayed appearance.

I don't think "educating" clients about quality is worth the effort. Just deliver code to a quality you are happy with and tell them that it takes as long as it takes (giving them feedback as regularly as you are capable of, so they get a sense of progress).

Good clients will understand and bad clients will filter themselves out quicker (which is a blessing in disguise even if they do sometimes give you money).

I prefer to let cold, hard reality do the teaching.

Yeah, I think it might be better to say "quickly, cheaply, or something that can be improved on in the future without starting again", because at least that way they're all at the same level.

To be fair, the business has no chance of success if nothing ships before the funds run out.

Though there is truth to that quip, not all the pairs of that triangle are equal. Its much easier to deliver quick and cheap, easier to deliver cheap and quality, and really hard to deliver quick and quality.

+1 "Programming is way more art than science" :)

I wouldn't say it is more, but I see it is a balance of both. I think the "MongoDB is Web scale" video shows the worst side of treating it as an art, when there is a more engineering type approach you can take.

Reply on news.ycombinator.com