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

61–70 of 105 posts

Re: Software Engineering principles to make teams better

#61

Post by rurp »

wlpu wrote: post #32
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.

It's easy to do immutability in python, just use NamedTuple for classes and tuple instead of list

I second this. My current job is the first place I've worked where the convention is to use NamedTuples for most things I've seen dicts used for on past projects and I quite like the pattern. It both makes the code more readable and avoids a number of subtle bugs that can crop up.

Re: Software Engineering principles to make teams better

#62

Post by yen223 »

tgb wrote: post #59
Fishkins wrote: post #36

Earlier quoted context omitted.

Say you have a batch job that performs tasks A–E, and each of those tasks might process thousands of records. At some point, something will go wrong that causes the process to crash, hang, or error over many records. If the code is not idempotent, you need to investigate exactly where things started going wrong and figure out how to resume the process at that point. You don't want to reprocess records and e.g. send o…

How do you make something idempotent if one of the effects is sending an email?

You can't make everything idempotent.

You should still try and make most things idempotent.

Re: Software Engineering principles to make teams better

#63

Post by RussianCow »

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 reintroduce old ones), and the benefit is almost always marginal. If your architecture allows it, it's better to sandbox working legacy code and leave it as-is than constantly rewrite it.

My own policy is: 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.

(Obligatory Joel Spolsky article on the topic that everyone has probably already read: https://www.joelonsoftware.com/2000/04/06/things-you-should-...)

[0]: ...with a possible exception if you're at a very large tech company with a lot of resources, where the testing/QA processes are a lot more thorough and it's possible to keep up with constant changes like this. But even then, seeing the amount of bugs introduced with each update to Facebook or Gsuite or any other large piece of tech, I'm skeptical.

Re: Software Engineering principles to make teams better

#64

Post by gravypod »

macintux wrote: post #42
wlpu wrote: post #32

Earlier quoted context omitted.

It's easy to do immutability in python, just use NamedTuple for classes and tuple instead of list

I’ll research those, thanks. Any suggestions for OSS projects that do so today?

This is a good talk that demos NamedTuple: https://www.youtube.com/watch?v=wf-BqAjZb8M

Re: Software Engineering principles to make teams better

#65

Post by RussianCow »

TeMPOraL wrote: post #22
chii wrote: post #19

Earlier quoted context omitted.

> Don't expect a better result after a rewrite but what's the point then? why spend effort for it, if it isn't expected to be better?

> but what's the point then? Learning. The result may not be meaningfully better, but you gain fuller understanding of the problem domain. The third rewrite might have a chance of being an improvement ;).

Next time my boss asks why I rewrote that component for the third time instead of doing real work, I'll answer "learning". ;)

In all seriousness, from a business standpoint, it's almost never worth rewriting anything unless you're already making significant changes to that code. The opportunity cost of not spending that time building things that get you paid is just too high—not to mention all the new bugs that you're likely to introduce.

Re: Software Engineering principles to make teams better

#66

Post by zentropia »

tgb wrote: post #59
Fishkins wrote: post #36

Earlier quoted context omitted.

Say you have a batch job that performs tasks A–E, and each of those tasks might process thousands of records. At some point, something will go wrong that causes the process to crash, hang, or error over many records. If the code is not idempotent, you need to investigate exactly where things started going wrong and figure out how to resume the process at that point. You don't want to reprocess records and e.g. send o…

How do you make something idempotent if one of the effects is sending an email?

Side effects go to the border of the app. You keep track if for some message X you have sended the email, so you garantie that you send it once.

Re: Software Engineering principles to make teams better

#67

Post by CodeMage »

macintux wrote: post #18
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…

> 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.

This was the first time I've encountered the mention of "referential transparency", so I looked it up and went down a deep rabbit hole. It seems that it's normally used to describe the property of not having side effects, however, I also found this long explanation on Stack Overflow: https://stackoverflow.com/a/9859966/58099

So now I'm more confused than when I initially read your comment. Do you mean "referential transparency" as in "expressions without side effects" or do you mean it in some other way that I don't understand yet?

Re: Software Engineering principles to make teams better

#68

Post by bob1029 »

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…

> 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 refactor bits and pieces to conform to a correct model, but it's going to be an uphill battle the whole way. 10x if you are already in production with business state tied to the legacy schema(s).

Most of the horrible things I have seen at code review time have a root cause somewhere in poor domain modeling.

For example: Someone put support for 2 customer addresses as facts directly in the Customer type, so now you can't deal with the new edge case of 5+ addresses per customer, or model the idea that the address might be shared between more than 1 customer (and/or some other business types).

If you didn't model for 3NF/BCNF/DKNF up front, you might as well start over from the beginning in my experience. If your problem domain is not that complex, you can probably survive with something really shitty, but the moment you enter into 50+ types, 1000+ facts and 100+ relations, things are impossible to manage without strong discipline in this area.

Re: Software Engineering principles to make teams better

#69

Post by TeMPOraL »

RussianCow wrote: post #65
TeMPOraL wrote: post #22

Earlier quoted context omitted.

> but what's the point then? Learning. The result may not be meaningfully better, but you gain fuller understanding of the problem domain. The third rewrite might have a chance of being an improvement ;).

Next time my boss asks why I rewrote that component for the third time instead of doing real work, I'll answer "learning". ;) In all seriousness, from a business standpoint, it's almost never worth rewriting anything unless you're already making significant changes to that code. The opportunity cost of not spending that time building things that get you paid is just too high—not to mention all the new bugs that you'r…

I wrote it a bit tongue in cheek, but honestly, I've recently started to consider writing the first solution as a pure learning exercise. I.e. when writing a new module/feature, I lean towards getting a solution implemented quickly, fully expecting to immediately scrap most (or all) of it, and write it again. Most of the time, this happens way before the code goes into review phase, so nobody knows I've actually written something twice.

In my experience, most of the insights cluster in two places: just as you start writing your solution, and just as you think you're done with it. So you want to get through the whole process quickly, just to learn the things you need to write a proper solution.

Related, from a different HN thread - https://news.ycombinator.com/item?id=27692710 - "action produces information".

Re: Software Engineering principles to make teams better

#70

Post by macintux »

CodeMage wrote: post #67
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.

This was the first time I've encountered the mention of "referential transparency", so I looked it up and went down a deep rabbit hole. It seems that it's normally used to describe the property of not having side effects, however, I also found this long explanation on Stack Overflow: https://stackoverflow.com/a/9859966/58099 So now I'm more confused than when I initially read your comment. Do you mean "referential tr…

I just mean it in the sense of functions without side effects on data in the program (I’m not fussed about I/O).
Post reply on HN