Live data from Hacker News

Are software engineering “best practices” just developer preferences?

floverfelt.org

41–50 of 369 posts

Re: Are software engineering “best practices” just developer preferences?

#41
post #34
post #4

Steven Sinofsky gave a talk and said something to the effect of, we've been building roads, bridges and edifices for thousands of years. So, best practices and solved problems abound---and even then we still get it wrong sometimes. Whereas, software engineering is maybe 70 years old (generously)? So, there is much to learn and a lot of "baseline" knowledge that has yet to be established. I think it's a good way to th…

Civil (and other engineering) got better because there was motivation to improve that came from multiple directions: literal lives at stake, the pride of good craftsmanship, iterative or even grand steps forward in knowledge, etc. Software engineering as a discipline is dominated by appeals to authority ("Clean Code", "Google does it this way", "Djikstra said so", etc.) without any (or at least not much) attempt to a…

I feel like I already spend 90% of my day gluing together various disparate APIs. Is this the logical conclusion to software development?

I adore the craft-like parts of software dev, wouldn't trade it for anything.

Re: Are software engineering “best practices” just developer preferences?

#42
post #5

Earlier quoted context omitted.

To make the comparison fair, in that world civil engineers would also have the ability to change the laws of physics.

And the bridge collapsing would usually not kill people but strip all their clothes. Also you can start a bridge in your garage.

The clients also usually don't want to pay for a stable safe bridge because the collapsing one is good enough.

Re: Are software engineering “best practices” just developer preferences?

#43
> the senior engineer had defined every single service class as an interface and then implemented that interface in an actual @Service. The logic from the senior engineer was that the interface represented the “contract” and the class the business logic.

This is mentioned as bad thing, but having service interfaces really helped in a large Java project I worked, where we had to reimplement and extract some important code. Using the interface for the new code made it much simpler to use a radically different implementation, and also made devs think about what the real interface should be, vs just coupling to some implementation.

Re: Are software engineering “best practices” just developer preferences?

#44
post #5

I get your friend, and there's another point he can make: Imagine a world with self taught Civil Engineers.

To make the comparison fair, in that world civil engineers would also have the ability to change the laws of physics.

Or you can just compare them to software engineers that work on critical software like launch systems and nuclear reactors.

Software can be just as reliable when there is a need for it. Thing is, 99% of the time you don't need those extra 9s.

Re: Are software engineering “best practices” just developer preferences?

#45
post #3

I get your friend, and there's another point he can make: Imagine a world with self taught Civil Engineers.

Oh yeah the last bridge collapsed, but that is a known issue. It is fixed in this bridge, trust me.

That’s sort of the Tacoma Narrows Bridge story.

Re: Are software engineering “best practices” just developer preferences?

#46
Right, but have you ever worked in a place where no practices at all are being followed? Where there are hacks after hacks, giant classes with giant methods, no interfaces, static methods, bad names everywhere, you need to find a bug? good look, you want to write a test to avoid regression? Ok that would take you 5 times more time.

I agree, following a “best practice” without understanding the “bad practice” that it’s trying to prevent is silly. But just discarding best practices because no one understands the reasons behind is also silly.

Re: Are software engineering “best practices” just developer preferences?

#47
post #7

Having an interface for a single implementation is just redundant. A class already has an interface - it's public API. Other than that I agree, most "best practices" are subjective and boil down to personal preference.

Having an interface let's you introduce versions or alternative implementations easily, this is important in a long run. It's much easier to handle the transitions, because you can have both versions in your code base and you can easily switch back to the old one if necessary. When you start with a class and you want to do similar thing, you either YOLO it and change everything at once, or you need to introduce an interface and replace every usage to use the interface to achieve a safer transition and you are back at the interface-class implementation with an extra pain.

Re: Are software engineering “best practices” just developer preferences?

#48
post #4

Steven Sinofsky gave a talk and said something to the effect of, we've been building roads, bridges and edifices for thousands of years. So, best practices and solved problems abound---and even then we still get it wrong sometimes. Whereas, software engineering is maybe 70 years old (generously)? So, there is much to learn and a lot of "baseline" knowledge that has yet to be established. I think it's a good way to th…

Furthermore, there are far fewer physical constraints in software, so the range of possible designs is dramatically wider.

(Actually I dare say that sotware itself has no physical constraints at all: software artifacts and software executions do.)

Re: Are software engineering “best practices” just developer preferences?

#49

> How can Software Engineers call themselves engineers when there’s no rules, governing bodies, or anything to stipulate what true Software Engineering is? So the world had no engineers before the creation of governing bodies? That doesn't sound right to me. Thus, I think this person's definition needs some tweaking.

Not quite, a governing body is what stipulates who can be called an engineer and who cannot (at least this is the case in Canada.)

Certainly those who did engineering-like work existed before governing bodies, you just never really knew whether they were any good, because there was no minimum set of competency defined.

Ironically, one might say this is what software development is like right now! It is both a blessing and a curse, the accessibility of modern software development is what makes it so great, pitfalls and all.

Post reply on HN