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

61–68 of 68 posts

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

#61

Post by ItsMonkk »

oddthink wrote: post #55
ItsMonkk wrote: post #44

Earlier quoted context omitted.

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 e…

I generally agree with your response. There is nuance and every project will be different and every team will be different.

There was a PM post this last week[0] where I can cite possible flaws. The PM creating this post has engineering experience, so it's possible that he will make all of the correct decisions, but he is also centralizing a big portion of the decision making. That can be good, especially if he is of the PBFD variety.

> "Do we absolutely need discount functionality at launch?"

This is a good question to have. You want to only build the MVP. But if you don't know what it will take to build[1], then you can't make that decision. If you make that decision, and don't communicate to the team that you made that decision, and they build a product that needs to be completely redone once that feature needs to be done, that's not ideal.

> "Which tasks depend on which other tasks?"

This is a good question to have. Another good question is: What parts of these tasks can we work on even if the entire story is dependent on some other task? Is the entire job going to take at minimum 23 weeks, or can we on week 1 spend a bunch of time doing "product cart price calculation" spike engineering task, while at the same time doing a "shopping cart containing product" spike task. Then when we get to the story, suddenly the implementation of the entire pipeline can be completed in a single sprint. If your engineers only see the story when its popped off of the top of the backlog, they won't be able to accomplish that.

[0]: https://news.ycombinator.com/item?id=27906886

[1]: https://xkcd.com/1425/

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

#62

Post by ycnews »

DanielBMarkham wrote: post #28

I do a weekly roundup of tech stuff.[1] I flagged this story for inclusion, mostly because of the types of conversation I'm seeing on HN today. This is not "New age bullshit", although I understand the sentiment. The most frustrating part about studying how teams self-manage for success is that management theory consists of a lot of words and emotions and very little concrete theory. That doesn't make any of it wrong…

re:"weekly roundup"> F# Is The Best Coding Language Today

Have you looked at http://nim-lang.org ?

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

#64

Post by gmfawcett »

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.

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

Isn't this exactly the kind of vague advice that GP was talking about?

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

#65

Post by atoav »

TeMPOraL wrote: post #15
atoav wrote: post #10

Earlier quoted context omitted.

> quality is not negotiable? Really? I read this as "certain principles must be upheld at any cost" and I agree with that. E.g. if your project is dealing with people's health data, not securing that database is a cut on quality you just shouldn't make. Or to phrase it the other way around: If your project cannot reach that basic quality level, maybe it should be ended right away, because it clearly lacks funding/res…

That's the problem with this list: you can read it any way you like, derive whichever conclusions you want. But then you're only looking into a mirror. On its own, the list is just a lot of feel-good bullshit, mixed with stuff that's just wrong. It has very low information content. > I read this as "certain principles must be upheld at any cost" and I agree with that. But that's you reading things that aren't in the…

What I argued here is not that you cannot and will not negotiate quality. I argued that taking it below a certain quality level is not an option for most people. You wouldn't for example not escape the commas present within the fields of an incoming csv file simply based on the fact that this would be bad engineering and allow injections or make your program crash. And I am not sure any customer could negotiate me into doing that, it would just be silly.

I was working in VFX where you always had to talk about quality, yet I didn't take certain jobs, because below a certain quality level VFX make no sense anymore (unless bad FX are the point of the movie) — below a certain level you won't be happy, the customer won't be happy, it won't be work that you can show etc.

Granted: coming to this from "quality is not negotiable" is a far stretch, but that was the way I initially read it. Maybe a better heuristic would be "Below a certain quality level, don't bother"

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

#66

Post by aaronchall »

yourenotsmart wrote: post #33
100011_100001 wrote: post #32

Reading the comments first I suspected this was an HN over-reaction to the list. However upon reading it myself I must totally agree. There is nothing actionable about this list. A lot of it is meant to sound wise, without any specifics. Definition of heuristics: > A heuristic, or a heuristic technique, is any approach to problem-solving that uses a practical method or various shortcuts in order to produce solutions…

> 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 find these actionable as well:

O - "Don't modify, extend instead."

I - "Don't group interfaces into a god object - separate them."

D - "Depend on abstractions not concrete implementations."

S is the most disputed but Uncle Bob occasionally clarifies (paraphrased, again): "Object definitions should be beholden to only one stakeholder group."

SOLID seems actionable enough to me... whereas Holub's article is a bunch of fluffy mothering statements.

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

#67

Post by Gupie »

gmfawcett wrote: post #64
Gupie wrote: post #51

Earlier quoted context omitted.

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.

> there are exceptions to most rules, but break them only if you know what you are doing and are able to justify doing so. Isn't this exactly the kind of vague advice that GP was talking about?

Perhaps, or perhaps it is a meta-rule, i.e. a rule about rules. Either way it is just obvious common sense IMO.

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

#68

Post by satisfice »

atoav wrote: post #10
satisfice wrote: post #2

Sloppy thinking… new age bullshit… most of it collapses under mild scrutiny. Some of it is okay. I just don’t get, after decades and decades, how our industry continues to tolerate bullshit. Quality is not negotiable? Really? Negotiation is not collaboration? Really? This is not just wrong, it’s almost gaslighting.

> quality is not negotiable? Really? I read this as "certain principles must be upheld at any cost" and I agree with that. E.g. if your project is dealing with people's health data, not securing that database is a cut on quality you just shouldn't make. Or to phrase it the other way around: If your project cannot reach that basic quality level, maybe it should be ended right away, because it clearly lacks funding/res…

I appreciate that you are looking at this with a charitable eye. There's a lot to be said for that. And yet, when someone words their heuristics in such absolute and categorical fashion, they stop sounding like heuristics and start sounding like moral ultimatums; which are anti-heuristic.

I, too, make lists of heuristics. And one way I test them is to ask "how could this be completely wrong? Is this really what I mean?" The common idea of negotiation is the process of coming to an agreement by each side being willing to give up something they want (at least in principle) in order to achieve something else they do want. It seems to me that collaboration involves a great deal of negotiation. So, is the OP talking about BAD negotiation? Then say so.

Post reply on HN