Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Heuristics for Effective Software Development: A continuously evolving list

holub.com

Post reply on HN
Print view View original

51–60 of 68 posts

Re: Heuristics for Effective Software Development: A continuously evolving list

#51

Post by Gupie »

Verdex wrote: post #50
Gupie wrote: post #49

Earlier quoted context omitted.

There are a number of agreed bad practises: long functions, deep nesting, obtuse identifiers, unrestricted use of gotos, global variables, no coding standard, premature optimisation, C macros, raw pointers...

False. Bryan Cantrill (OS developer who used to work at sun microsystems) talks about how the C macros are great [1]. John Carmack talks about how long functions can be better than short ones [2]. Every piece of advice that I've heard has had a contradiction coming from a preeminent developer. To be fair, yes, people do agree on bad practices. They are just often wrong. People agreeing that something is true doesn't…

Not false.

Sure there are exceptions to most rules, but break them only if you know what you are doing and are able to justify doing so.

Re: Heuristics for Effective Software Development: A continuously evolving list

#52

Post by Gupie »

Verdex wrote: post #48
Gupie wrote: post #46

Earlier quoted context omitted.

"agreed upon deliverables" is one definition of output. I think he is talking more generally, e.g. lines of code, over-long email, unnecessarily verbose documentation, ..., I could go on indefinitely. But you are really arguing in general against such lists like this, that don't "examine the nuance". But perhaps they are useful discussion point or memory joggers. And shouldn't the senior members of a team or managers…

> And shouldn't the senior members of a team or managers explain to novices the importance of meeting such milestones that you mentioned? I basically read the whole list as: "How do be successful? Step 1: Be successful. Step 2: Be successful at purple. etc" Some of it sort of makes sense. Some of it might as well be gibberish. None of it is useful without a bunch of senior members of a team who have been successful b…

The prefer "outcomes to output" is not a "How do be successful? Step 1: Be successful. Step 2: Be successful at purple". I can see the use of such a list for example on a team wiki as a reminder that you don't get credit for writing a 3 page email when a 6 liner would be as useful.

I can see the use of such a list for example on a team wiki as a reminder of what the team considers good practice.

Re: Heuristics for Effective Software Development: A continuously evolving list

#53

Post by cheradenine_uk »

Gupie wrote: post #51
Verdex wrote: post #50

Earlier quoted context omitted.

False. Bryan Cantrill (OS developer who used to work at sun microsystems) talks about how the C macros are great [1]. John Carmack talks about how long functions can be better than short ones [2]. Every piece of advice that I've heard has had a contradiction coming from a preeminent developer. To be fair, yes, people do agree on bad practices. They are just often wrong. People agreeing that something is true doesn't…

Not false. Sure there are exceptions to most rules, but break them only if you know what you are doing and are able to justify doing so.

I often think there's an equal and opposite other side to that: Don't /make/ any rules unless you know what you are doing and able to justify them (and their scope of effectiveness).

I've recently had to work on a project controlled by someone who's swallowed "clean code" and a couple of C# style guides and now just unthinkingly applies what he thinks he's read. E.g: you are not allowed any comments in this codebase. No variable may be typed. Period.

Both extremes are.. not good.

Re: Heuristics for Effective Software Development: A continuously evolving list

#54

Post by charles_f »

> Outcomes matter more than output. A focus on output yields sub-par outcomes.

In my experience, this is true mostly for planning and control. It's important to remember the goal when building something, but at some point you need to focus on the output as well. "a focus on outcomes only doesn't yield any output"

Re: Heuristics for Effective Software Development: A continuously evolving list

#55

Post by oddthink »

ItsMonkk wrote: post #44
oddthink wrote: post #37

Why do agile-folks seem to hate product managers so much? This comes out in #13, #19, and #20 (well depending on exactly what they mean by "managing".) I find it really helps to have someone dedicated to the product side, so they can help with prioritization, generating ideas for what to try next, keeping track of the research, and tracking the launch process and metrics. We could, I suppose, distribute all of that t…

I'm not yet an expert on this, but I'm coming to the same intuition that the writer has so let me attempt to explain. Let's say we have 4 domains, and 4 domain experts. P is product, B is backend, F is frontend, and D is database(this is heavily simplifying, I know there are many sub-domains within each depending on the scope of the project). Each new feature starts with the P expert working with the team translating…

I can see this as being a problem, like you said, if there isn't communication, but I don't think that demanding a "PBFD" expert is realistic or scalable.

But in my experience the PM is technical enough to understand what's going on. (Can write some SQL to answer questions, possibly ex-engineer themselves, etc.) They're in the same meetings, same email threads, looking at the same set of OKRs, etc. It's part of the engineers' jobs (B/F/D whatever) to communicate their constraints and their ideas (both product and pure-tech) to the PM, and it's part of the PM's job to take those into account when advocating for what should be done.

Similarly, the more the engineers know each others' specialties, the better they can coordinate. It's probably more important for everyone to have "a little bit of product" in them, but that doesn't mean we don't need a product-specialist.

When it's time for quarterly planning, the PM's voice is definitely loud, but they're still just one voice in the room. They're the one accountable for the product, which gives them some leverage, but the other voices are there (TLs, managers, etc.)

Now I can see this going terribly wrong if the scale is off (only one PM for too many engineers), or if communication breaks down (PM scribbles a "design" on a napkin and faxes it over), or if only the PM is consulted for planning. But the problem there is that communication broke down, not that it's bad to have a PM.

Re: Heuristics for Effective Software Development: A continuously evolving list

#56

Post by Graffur »

cheradenine_uk wrote: post #7

I wish there were a list for "effective actually completing your Kickstarter", wherein Holub took money for an "Agile video class" [1], which was supposed to be delivered in an Agile way. That was 4 years ago. First the timeline got pushed out, then I rather gather he's just got bored and drifted on. How ironic is the non-delivery of an agile training course, supposedly delivered in an agile way, that utterly fails t…

Did everyone get their money back? Either way that is quite embarrasing

Re: Heuristics for Effective Software Development: A continuously evolving list

#57

Post by dgb23 »

Guthur wrote: post #45
dgb23 wrote: post #26

Earlier quoted context omitted.

From his blog[1] > External pressure (accountability) and internal pressure (responsibility) are simply not needed in a healthy culture. As in a relationship, the word “accountable” is rarely, if ever, heard in high functioning organizations. I can't quite determine if he is ahead of his time or a snake oil salesman. [1] https://holub.com/noaccountability/

Yikes, I've liked some of Alan's talks but I think he's gone a little of the deep end with this one. For me responsibility is a key component of getting shit done. You do need an environment where fear is driven or so that if someone feels they can not fulfil they're responsibility they can come forward for support. But in my experience if everyone is responsible for something it often ends up no one is. Accountabili…

I think the key here is that responsibility is taken. It is a free act that one is aware of when assuming power. Has nothing to do with finger pointing but rather with fairness and trust. Making mistakes is human, admitting them is strength and leads to learning. I see more problems with ignoring responsibility than with taking it.

Re: Heuristics for Effective Software Development: A continuously evolving list

#58

Post by 100011_100001 »

Verdex wrote: post #42
yourenotsmart wrote: post #33

Earlier quoted context omitted.

> A lot of it is meant to sound wise, without any specifics. This unfortunately applies to most of the popular advice in our industry. You could argue that "meant to be wise, without any specifics" is a requirement for a meme to get picked up and recognized by a large enough mass of people in order for it to become viral. Consider if you can apply anything in SOLID in an actionable way. None of it is actionable, exce…

I'm getting misty-eyed over here. Seriously, I thought I was the only one. I have heard almost no advice that's anywhere near actionable in our industry. The way I see it is that we have no objective ways to even talk about good code versus bad code (and forget all of the support tasks like "can we estimate this"; those require some objective understanding on how terrible the code happens to be). We've got code smell…

The problem is if you take any actionable idea as law, there is a pendulum swing to the other side to the point that you need a counter actionable idea to reset it.

OOP started like that, as an initial concept it made a lot of sense. Try to force OOP into anything you have a problem. Functional Programming, is the counter to OOP design, but it also has problems.

Same is true to having short functions doing one thing vs abstracting too early. Our industry is filled with counter points.

Even the "recent" shift to microservices, taking to the extreme they create new problems that monoliths didn't have.

...this is one of my biggest struggles as a developer currently, conflicting ideas that all make sense and trying to figure out which one I should apply for a specific piece of code.

Re: Heuristics for Effective Software Development: A continuously evolving list

#59

Post by 100011_100001 »

Verdex wrote: post #50
Gupie wrote: post #49

Earlier quoted context omitted.

There are a number of agreed bad practises: long functions, deep nesting, obtuse identifiers, unrestricted use of gotos, global variables, no coding standard, premature optimisation, C macros, raw pointers...

False. Bryan Cantrill (OS developer who used to work at sun microsystems) talks about how the C macros are great [1]. John Carmack talks about how long functions can be better than short ones [2]. Every piece of advice that I've heard has had a contradiction coming from a preeminent developer. To be fair, yes, people do agree on bad practices. They are just often wrong. People agreeing that something is true doesn't…

I remember reading John Carmack's comments a few years back and it kind of broke my coding style because it seemed like I did everything opposite of his suggestions.

I haven't recovered since. For anyone interested, here is my notes summary from various articles and videos from John.

### John Carmack

* Do-always, then inhibit or ignore strategy

* Common pattern for me: get first results with hacky code, then write a brand new and clean implementation with the lessons learned, so they both exist and can be cross checked.

* If a function is only called from a single place, consider inlining it.

* If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that.

* If there are multiple versions of a function, consider making a single function with more, possibly defaulted, parameters.

* If the work is close to purely functional, with few references to global state, try to make it completely functional.

* Try to use const on both parameters and functions when the function really must be used in multiple places.

* Minimize control flow complexity and "area under ifs", favoring consistent execution paths and times over "optimally" avoiding unnecessary work.

Post reply on HN