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

11–20 of 105 posts

Re: Software Engineering principles to make teams better

#11

Post by AdamCraven »

sublimefire wrote: post #7

Give it some time and it will end up being "The 5 Pillars of the AWS Well-Architected Framework" or something similar. Someone already mentioned that "time" is absent here. Hence you cannot generalize. Each company should probably write their own principles and make it part of their identity.

Indeed. That is definitely the next steps to allow individuals and eventuall companies to create their own principle lists.

There are no principles that make sense in every situation, there are no teams that will have the same principles.

Imagine being able to have a team and then adopt those principles easily into your team? That's the goal.

Re: Software Engineering principles to make teams better

#12

Post by AdamCraven »

vageli wrote: post #5

What does "Iterate in Thens" mean?

Well to quote the "what" of the principle https://principles.dev/p/iterate-in-thens/

You should iterate sequentially on a focused chunk of work at a time. Once that chunk has been completed THEN start on the next chunk of work. This is opposed to doing multiple chunks of different of work in parallel.

It's really a way of working as opposed to operating on code.

Re: Software Engineering principles to make teams better

#13

Post by AdamCraven »

darkrai0707 wrote: post #2

This is a great initiative. It would be great if across each principle, we can have examples on how this principle helps to improve the code quality

Some principles do have this already, it depends on the princple. They tend to be more code focused, such as compute properties when possible: https://principles.dev/p/compute-properties-when-possible/

It would be hard to do it for every case, as principles interact together to create more complex behaviors. I'll be discussing this more in "emergent behaviors" in "principle-driven engineering" at some point. But the essence is architecture can arise from a few principles together. It's a bottom up approach to architecture where team members understand the "why" so there are shared mental models between the team.

Re: Software Engineering principles to make teams better

#14

Post by AdamCraven »

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 really like that you've thought about these - and 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.

It's not really about better or worse, what I've found is different people have different backgrounds and what principles they find useful is based on several things, which may be immuntable - such as strongly held values.

You're never going to make me not care about aesthetics for example, as that is intrinsic to me and that will affect the principles I like and ultimately the people that I work best with.

An analogy I like to think about is that people with very different principles are like two people holding a rope and pulling away from each other - you aren't going to get anywhere fast.

Whereas people with similish principles, will generally go in the right direction. Sure, they'll get tangled up from time to time and you won't always want to get in exactly the same way. But there's a collaborative nature to it and you'll both improve.

Re: Software Engineering principles to make teams better

#15

Post by Jenk »

AdamCraven wrote: post #14
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 really like that you've thought about these - and 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. It's not really about better or worse, what I've found is different people have different backgrounds and what principles they find useful is based on several things, which may be immuntable - such as strong…

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

Re: Software Engineering principles to make teams better

#16

Post by mrits »

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…

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

Re: Software Engineering principles to make teams better

#17

Post by AdamCraven »

Jenk wrote: post #15
AdamCraven wrote: post #14

Earlier quoted context omitted.

I really like that you've thought about these - and 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. It's not really about better or worse, what I've found is different people have different backgrounds and what principles they find useful is based on several things, which may be immuntable - such as strong…

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

Codifying the principle for the first time takes effort and people can iterate on it to make it better over time. Many people may have had similar thoughts before, but if it's not a general principle already being used the first to turn it into a principle - to put a stake in the ground - benefits everyone and can help improve everyone's capability.

I believe the author should be rewarded for that effort, as long as it is their own unique work.

Re: Software Engineering principles to make teams better

#18

Post by macintux »

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.

Re: Software Engineering principles to make teams better

#19

Post by chii »

mrits wrote: post #16
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…

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

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

Re: Software Engineering principles to make teams better

#20

Post by hammock »

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?

Post reply on HN