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

31–40 of 105 posts

Re: Software Engineering principles to make teams better

#31

Post by lupire »

AdamCraven wrote: post #17
Jenk wrote: post #15

Earlier quoted context omitted.

> feel free to submit them not only will you get a founding badge but if you're the first person to create it you'll be known as the source of them in the future. That sounds wrong. As in "I could upload quotes from Gang Of Four books and claim I am the source" wrong.

A lot of thought has gone into the licensing. Hopefully I've covered all bases. You can't be an author if you aren't the author of a principle or the principle is too generic. If the principle is already open source (e.g. on wikipedia, has a creative commons license) you can submit it but not claim you are the author for it and submit it under the same licensing terms (CC-BY-SA) as long as it doesn't break the licens…

This sea a lot more work for no benefit, compared to just writing a (hypertext) book and citing sources.

Re: Software Engineering principles to make teams better

#32

Post by wlpu »

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.

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

Re: Software Engineering principles to make teams better

#33

Post by AdamCraven »

chadlavi wrote: post #25

> Note: This visualization was designed for screens larger than 1024 x 1024 and for desktop-style interactions. You can proceed if you'd like. Why would you put in the work to warn people they'll have a bad time instead of just fixing the bad time.

Can you show me where that is or what visualization that is?

I haven't put anything on the website intentionally, perhaps it's auto generated.

The only page that I haven't purposely optimised for mobile is the editor, as you can't really create principles on your mobile.

Re: Software Engineering principles to make teams better

#34

Post by BurningFrog »

Scarbutt wrote: post #30
mrits wrote: post #16

Earlier quoted context omitted.

Don't expect a better result after a rewrite. Be prepared to accept that.

You make it sound as they are talking about full rewrites but it's actually about rewriting stuff here and there. You are also assuming one just rewrites stuff blindly and randomly without any prior new insight.

I took that to mean refactoring the code, not throwing it away and start over.

Re: Software Engineering principles to make teams better

#35

Post by AdamCraven »

titzer wrote: post #27

Is it just me, but is this meme version of software engineering absolutely the lowest information density achievable? Seriously. This is a heavily-involved topic, where any project might require hundreds to thousands of hours of development, and we have five second soundbytes as principles. Ugh.

In software engineering, the smallest behaviors interact to cause more complex ones.

In most teams, it's hard to point to those small behaviors because they have become habitual and you may have forgotten what they are. Forgotten the "why".

What I see in teams that don't work well, is teams don't have that guidance or don't share similar mental models to allow them to work effectively together. So you end up arguing at a higher level than the actual problem because you can't put your finger on what you believe.

Principles build capability. Take Redux, it has just three core principles: https://redux.js.org/understanding/thinking-in-redux/three-p... and from those core principles you can almost build the whole framework.

But more importantly it provides capability and confidence to people using the framework to extend if needed in a "redux" way. Instead of looking at the documentation, they know the authors intent. The "Why"

That said, the site is really in it's earlist phase and the principles will be improved over time with more in depth information as more people contribute. Eventually, a voting system will be in place so the best principles will come to the top.

Re: Software Engineering principles to make teams better

#36

Post by Fishkins »

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?

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 out duplicate emails or double-increment some number you're tracking. If the code is idempotent, conversely, you can just start the whole process over again without having to worry about any of that.

Similarly, many systems involve consuming from some message queue. It's basically impossible to guarantee exactly-once delivery in most systems. You either have to risk missing a message, or having it delivered multiple times. If you're running idempotent code, you can always err on the side of redundant delivery without any ill effects.

Re: Software Engineering principles to make teams better

#38

Post by omegalulw »

rcfox wrote: post #24
e40 wrote: post #21

Earlier quoted context omitted.

And is another way to say this "side-effect free"?

The Linux shell command 'touch foo' is idempotent, but not side-effect free. Reading a variable shared between threads without a lock is side-effect free but not idempotent.

Reading a variable isn't side-effect free either :P

Re: Software Engineering principles to make teams better

#39

Post by AdamCraven »

lupire wrote: post #31
AdamCraven wrote: post #17

Earlier quoted context omitted.

A lot of thought has gone into the licensing. Hopefully I've covered all bases. You can't be an author if you aren't the author of a principle or the principle is too generic. If the principle is already open source (e.g. on wikipedia, has a creative commons license) you can submit it but not claim you are the author for it and submit it under the same licensing terms (CC-BY-SA) as long as it doesn't break the licens…

This sea a lot more work for no benefit, compared to just writing a (hypertext) book and citing sources.

The eventual benefit is having access to many community sourced principles as a resource, which are getting better over time as people contribute.

Then being able to create your own lists for unique situations. Say "Lupire's CTO list" or "Lupire's management principles" and to share that with your team or as a reminder to yourself.

Of course you should always be able to export it and put it in a format that's useful to you. And that's been really important to the design. From using markdown format to embedding license information and meta data with the principle, it should help a lot with portability.

Post reply on HN