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

Software Engineering principles to make teams better

principles.dev

Post reply on HN
Print view View original

91–100 of 105 posts

Re: Software Engineering principles to make teams better

#91

Post by RussianCow »

bob1029 wrote: post #68
RussianCow wrote: post #63

Earlier quoted context omitted.

I agree with everything except for this: > 4. Delete code, delete tests, re-write stuff, re-write it again. Painful? Keep doing this till you get to the other side and feel liberation and empowerment, took me years to get past wincing at the idea of re-writing that thing AGAIN With experience I've realized that rewrites are almost never a good idea[0]. They are time consuming and inevitably introduce new bugs (or rei…

> With experience I've realized that rewrites are almost never a good idea [...] If your architecture allows it, it's better to sandbox working legacy code and leave it as-is than constantly rewrite it. What if your architecture is the problem? If you got the domain model wrong and you have deeply-nested complex types used throughout, you will never break free without a clean sheet rewrite. Certainly, you can refacto…

I don’t disagree in principle, but I have also never encountered architectural problems so deep that it was impossible to solve them piecemeal. I’m sure they exist, and in those cases I’d say a rewrite is probably worth it in the long run, but I haven’t seen it in practice.

Re: Software Engineering principles to make teams better

#92

Post by travisjungroth »

ketozhang wrote: post #85
macintux wrote: post #18

Earlier quoted context omitted.

> Use immutability by default, even in languages that make that harder than it should be That and referential transparency are huge wins. It is a shame languages like Python make it such a challenge.

Immutability isn't so difficult to do with Python language itself for any object. The push back is culture and practice of "we are all adults here" and that influences the language to make it forcing immutability awkward. For example, let's assign a constant variable to a sequence; should you do use list or tuple (FOO = [1,2,3] or FOO = (1,2,3) )? It doesn't matter, the constant capitalization discourages you to muta…

I don’t want constants. I want immutability. The problem isn’t someone reassigning FOO. It’s them changing the data that FOO represents. So I’d love to just use Python and pass around tuples, strings, frozensets and a homemade frozendict, but the performance is terrible. Any change means a full copy of the whole data structure.

Re: Software Engineering principles to make teams better

#93

Post by RussianCow »

gregmac wrote: post #72
RussianCow wrote: post #63

Earlier quoted context omitted.

I agree with everything except for this: > 4. Delete code, delete tests, re-write stuff, re-write it again. Painful? Keep doing this till you get to the other side and feel liberation and empowerment, took me years to get past wincing at the idea of re-writing that thing AGAIN With experience I've realized that rewrites are almost never a good idea[0]. They are time consuming and inevitably introduce new bugs (or rei…

My thinking definitely aligns with yours on this: > if you're making significant changes to a unit of code anyway, clean it up or rewrite it; otherwise, make the smallest change necessary and leave it alone. If it ain't broke, don't fix it. Don't be afraid to rewrite something when it needs it, and build knowing it's very possible you'll rewrite later. If there are good unit tests, and it's a sufficiently small/decou…

> If there are good unit tests, and it's a sufficiently small/decoupled piece of code, then rewriting is not so bad. These are all self-reinforcing things: small, decoupled code tends to be easy to rewrite; Testable code tends to be decoupled.

The problem with this mentality is that everyone thinks they write “good unit tests”, but bugs are still found in production. :) You can’t use unit tests as justification for software being reliable; being battle tested in the real world is a much better indicator in practice.

I mostly agree with your other points, although I would still advocate doing these rewrites in as small of pieces as possible, in a way that’s as backwards compatible as possible, instead of all at once. I think you may be saying roughly the same thing, but this thread has shown that people have different definitions of “rewrite”, so it’s hard to tell. :)

Re: Software Engineering principles to make teams better

#95

Post by gregmac »

RussianCow wrote: post #93
gregmac wrote: post #72

Earlier quoted context omitted.

My thinking definitely aligns with yours on this: > if you're making significant changes to a unit of code anyway, clean it up or rewrite it; otherwise, make the smallest change necessary and leave it alone. If it ain't broke, don't fix it. Don't be afraid to rewrite something when it needs it, and build knowing it's very possible you'll rewrite later. If there are good unit tests, and it's a sufficiently small/decou…

> If there are good unit tests, and it's a sufficiently small/decoupled piece of code, then rewriting is not so bad. These are all self-reinforcing things: small, decoupled code tends to be easy to rewrite; Testable code tends to be decoupled. The problem with this mentality is that everyone thinks they write “good unit tests”, but bugs are still found in production. :) You can’t use unit tests as justification for s…

> You can’t use unit tests as justification for software being reliable; being battle tested in the real world is a much better indicator in practice.

My point on unit tests to support a rewrite is that it can catch a lot of edge cases, and you can remain reasonably certain you didn't break things if tests are still passing when you're done.

But otherwise I totally agree -- you can have as many tests as you want, with whatever coverage numbers you want, and it will still fall down in the real world. I don't focus on coverage or being dogmatic about TDD. I like to heavily unit test algorithms/regexes/etc -- anything with a defined input and output. At the same time, I hate testing 'glue' code (like an MVC controller), and would way prefer to rewrite it to be so simple it either works or it doesn't work at all (causing a big, obvious failure).

As bugs are found in the real world, in the ideal case write a test which basically guarantees that bug never happens again. Not always possible or takes such a massive effort that it isn't worth it, but usually it pays off.

> I would still advocate doing these rewrites in as small of pieces as possible, in a way that’s as backwards compatible as possible, instead of all at once.

Yes, exactly, that's what I was trying to get at. Big rewrites are hard to get approval/agreement to start, hard to actually do and often unsuccessful. Worse, a team with the mindset "ah, it's okay if we cut corners here, we're going to rewrite this whole thing someday" will rack up a serious amount of technical debt -- and make that big rewrite even harder. Ironically this makes a big rewrite even harder to start and succeed, but also more necessary.

Small continuous rewrites are a way of constantly improving quality, while avoiding a lot of these traps.

Re: Software Engineering principles to make teams better

#96

Post by ArnoVW »

hammock wrote: post #20
CraigJPerry wrote: post #6

I think i’ve got a slightly different take - i’m not saying my take is any better though. If we’re talking engineering principles, not team dynamics, then it’s: 1. Use immutability by default, even in languages that make that harder than it should be 2. Understand how liberating idempotency is 3. Divide and conquer, use abstraction to make hard problems manageable 4. Delete code, delete tests, re-write stuff, re-writ…

> 2. Understand how liberating idempotency is Can you give some examples?

Idempotecy means you can run something several times and it will do the same thing.

Let's say you're controlling a factory and you have a function that fills a reservoir. A naive way would be to define the semantics of the operation as "send enough liquid" and open the circuit for 10 minutes when activated. Since it takes 10 min to fill, all is good.

But what if your program crashes and you have to rerun. If the reservoir was already semi-filled, you will overflow it.

If the semantics of the operation is "send liquid until 'full' sensor indicates you're done", that's liberating. You no longer have to worry about overflowing the reservoir.

Re: Software Engineering principles to make teams better

#97

Post by bilalq »

AdamCraven wrote: post #76
bilalq wrote: post #71

It'd be cool if counter-points to a principle could also be documented alongside it. Reasoning that highlights why you may not want to adopt a principle is helpful when considering it. For example, take "One single source of truth". >Data should be held in one location, duplicates of that data should be by reference only. >Why >Changes to data are always propagated to the rest of the system. >Mutations to the data ne…

It's funny you chose that principle in particular because it does have an exception listed: https://principles.dev/p/one-single-source-of-truth/ > Exceptions > Highly distributed systems - Some systems rely on data consistency to be reached eventually or may never need to have accurate data. I've written about exceptions here: https://principles.dev/documentation/#exceptions-optional In general, exceptions should be…

Haha, that's an interesting coincidence. I initially clicked into a few that didn't have exceptions listed and just picked that one when writing my comment. I just copied/pasted the beginning and didn't expect the extra section there.

Being able to stack rank principles is interesting. I think in practice, different principles apply to different use-cases and systems. There may be a certain set of principles for "critical" functionality pieces, but maybe a different set for features like reporting (such as staleness of data).

Amazon's leadership principles aren't specific to engineering, but they keep competing ones with tension between them all the same (e.g., "Bias for Action" vs "Insist on the Highest Standards").

Re: Software Engineering principles to make teams better

#98

Post by lowercased »

lowercased wrote: post #83
bobthepanda wrote: post #51

Earlier quoted context omitted.

Meaningful improvement is in the eye of the beholder. There's the old tale of how Google found out 500ms in latency was a 1% drop in traffic. http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.... 20 to 17 minutes is a 15% time savings still.

25 hours to 20 minutes is insane. The process ran daily and only needed to run daily. 20->17 was unnecessary and a waste of time.

Can't edit my post - posted too soon. 20 min -> 17 min was unnecessary for the client, but... 2 other people got to 'share' in the credit, because 'the team' got this down from 25 hours to 17 minutes. They got to learn something, after telling me it was 'impossible', but... that wasn't enough. They needed to put their fingerprints on it, then got to take credit for something. And took it they did. Annoying as hell, 15+ years later.

Re: Software Engineering principles to make teams better

#99

Post by AdamCraven »

bilalq wrote: post #97
AdamCraven wrote: post #76

Earlier quoted context omitted.

It's funny you chose that principle in particular because it does have an exception listed: https://principles.dev/p/one-single-source-of-truth/ > Exceptions > Highly distributed systems - Some systems rely on data consistency to be reached eventually or may never need to have accurate data. I've written about exceptions here: https://principles.dev/documentation/#exceptions-optional In general, exceptions should be…

Haha, that's an interesting coincidence. I initially clicked into a few that didn't have exceptions listed and just picked that one when writing my comment. I just copied/pasted the beginning and didn't expect the extra section there. Being able to stack rank principles is interesting. I think in practice, different principles apply to different use-cases and systems. There may be a certain set of principles for "cri…

It's the main feature that's missing from this - I'm working on it - context sensitive principle lists, with ranking, which can slice up reality in the way you've said.

Going to be a hard one to get right, so I'm taking my with that one.

Re: Software Engineering principles to make teams better

#100

Post by antb123 »

RussianCow wrote: post #63
CraigJPerry wrote: post #6

I think i’ve got a slightly different take - i’m not saying my take is any better though. If we’re talking engineering principles, not team dynamics, then it’s: 1. Use immutability by default, even in languages that make that harder than it should be 2. Understand how liberating idempotency is 3. Divide and conquer, use abstraction to make hard problems manageable 4. Delete code, delete tests, re-write stuff, re-writ…

I agree with everything except for this: > 4. Delete code, delete tests, re-write stuff, re-write it again. Painful? Keep doing this till you get to the other side and feel liberation and empowerment, took me years to get past wincing at the idea of re-writing that thing AGAIN With experience I've realized that rewrites are almost never a good idea[0]. They are time consuming and inevitably introduce new bugs (or rei…

Imagine if we made bridges this way... Lets just knock it down and rebuild. Who cares about cost or traffic.

In some ways software engineering is so immature compared with other engineering disciplines.

I believe more in boy scout - "if you touch it leave it better than when you arrived".

:-)

Post reply on HN