Hacker News Reader

Comment by kristianc | Hacker News Reader

> "Make a tool that does X. We need it by Friday so we can use it for Y."

> Me: "Ok! I can probably whip up something quick and dirty in python that gets the job done!"

And this, when abstracted across an entire team or company, is what gets us unreadable code and hopelessly buggy software. Productive does not always equal effective.

View on HN

This is a problem of incomplete specifications.

"Make me a tool that extracts, collates and graphs data from this spreadsheet. We just need it to run once this friday"

"Done, super fast, slightly buggy python script it is!"

"Every month we need a tool to pull data from multiple sources, and push it to a reporting framework. It needs to be scalable and robust... oh and we need it by friday"

"Well, you're not getting it by Friday."

Deadlines should be a conversation, not a demand.

Fast<->Cheap<->Good/Pick 2 is up there with the second law of thermodynamics in its inviolability.

Meanwhile "I'll learn a new language to do this" when abstracted across an entire team or company leads to code that no one knows how to maintain when the one person who wrote it leaves.

I feel the same way about "clever" code. Most of the time "clever" code isn't really any more efficient than a naive approach, it's just a way for a developer to code golf at work by abusing / using uncommon syntax or idioms. Which is really a net negative since other people need to be able to read your code

Yep! "Clever" code always reminds me of Kernighan :

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

It seems to me that the smarter someone attempts to appear the less smart they truly are. True intelligence appears as clarity.

The converse, when abstracted across an entire team or company gives us architecture astronauts that don't ever actually ship anything that works.

Great so we've established you want to be somewhere in the middle.

It's also what gets us great code and reliable software, when done properly. Engineering is all about tradeoffs. A major tradeoff is time versus... just about anything else. Deadlines help you know how to make that tradeoff properly.

Reply on news.ycombinator.com