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

How to Build Good Software

csc.gov.sg

Post reply on HN
Print view View original

21–30 of 247 posts

Re: How to Build Good Software

#21

Post by lifeisstillgood »

wenc wrote: post #16
9nGQluzmnq3M wrote: post #14

The article appears to be written by Singaporean prime minister Lee Hsien Loong's son, Li Hongyi. http://theindependent.sg/li-hongyi-singapore-has-a-lot-of-pr...

Also, his brother Li Haoyi wrote Ammonite, a well-known Scala REPL.

Sorry - the son of Singapore's Prime Minister is a Scala Hacker ...

I keep on saying that Software Literacy is a real thing. And that this current generation of leaders are like Charlemagne - he was the first Holy Roman Emperor and the last who was illiterate.

Interesting to see it in practise

Re: How to Build Good Software

#22

Post by mmatants »

mr_tristan wrote: post #17

This struck a chord with me: "Software Is about Developing Knowledge More than Writing Code" I've experienced more issues caused by management passing around tasks between teams and never paying attention to knowledge and knowledge transfer. What's amazing, is that in over 18 years as a software engineer, I've seen this so many times. Teams will function well, then the institution tries to change. Often they will try…

Apparently, Peter Naur (the N in BNF) wrote this up nicely back in 1985 in "Programming as Theory Building": http://pages.cs.wisc.edu/~remzi/Naur.pdf

Re: How to Build Good Software

#23

Post by unityByFreedom »

jrumbut wrote: post #13

I thought "what a bold title, if someone's figured it out we can just close HN" and upon reading, hey it's not far off. The following is a wonderful point I have hardly ever heard said directly: "The main value in software is not the code produced, but the knowledge accumulated by the people who produced it."

weird, I've heard it said frequently for decades in various forms,

"value your knowledge workers"

"your employees are your most valuable asset"

Some companies don't treat employees well, and some employees at good companies feel they are not treated well enough

If the above quotes do not strike a chord with you, you might just be a software engineer who thinks you're more important than non-SEs.

Re: How to Build Good Software

#24

Post by al_form2000 »

diafygi wrote: post #9
commandlinefan wrote: post #2

How many more decades are we going to have to spend learning this lesson before we learn it?

There's a saying in most other fields of engineering (civil, chemical, mechanical, etc.): "Regulations are written in blood." A whole lot of bridges collapsed and a whole lot of people died before strong requirements were put in place. It seems we are on the path to repeat history with software engineering, what with how software and the internet is being developed with such little regard for public safety and long t…

Thumbs up.

Re: How to Build Good Software

#26

Post by al_form2000 »

crimsonalucard wrote: post #15

Nice Post. But everyone needs to understand something. Even if you follow these principles to the letter T, you can still produce very bad software. In fact you can also find many cases where people did the exact opposite of what this guy said and still produced great software. I'm sure many people can name examples of software that just came together out of blind luck. Why? Because there is no formal definition for…

We know a great deal about dynamics,kinematics, thermodynamics and generally the physics that governs car components, yet we are a long way from an algorithm that applied to a car will produce a better car. My guess is that doing that for software is as hard, if not harder.

Also the sentence 'algorithms that applied to algorithms produce a better model' has a strong smell of halting problem, at least to this nose.

Re: How to Build Good Software

#27

Post by kilburn »

akersten wrote: post #5

One of the principles the article highlights is that additional features make a software complex and therefore more likely to fail. This is true, but I'd argue it's not for the reason the article claims. The claim is: > Stakeholders who want to increase the priority for a feature have to also consider what features they are willing to deprioritise. Teams can start on the most critical objectives, working their way do…

> In other words, the argument is "competing priorities in a large-scale project make it more likely to fail, because stakeholders can't figure out which ones to do first."

This is a misinterpretation of the article's claim. The article very explicitly begins by saying that the best recipee to increase a project's chances to success is to:

> 1. Start as simple as possible;

> 2. Seek out problems and iterate;

The priority part reads to me as a way to determine which features are critical (and hence part of the as simple as possible set) and which ones are not (and hence you should not build "yet"). The underlying vibe being that these other features should probably never get implemented because once the critical ones get built and the software is put to use you will actually find other critical fearures that solve actual problems found through usage.

That is, only when you find that one of the initially non-critical features has become a hindrance for users actually using your software you should seek to implement it.

I really think this would be a better way to build software, just as much as I think that you will have a very very hard time getting any management on board with it...

Re: How to Build Good Software

#28

Post by soup10 »

>The better your engineers, the bigger your system can get before it collapses under its own weight. This is why the most successful tech companies insist on the best talent despite their massive size.

Translation: the successful tech companies have so much poorly documented legacy enterprise spaghetti code and tooling that they need the best talent they can get just to make sense of it and maintain it

Re: How to Build Good Software

#29

Post by nneonneo »

I found this to be an incredibly accessible and easy to read guide for software development. It’s a very short read - just a few minutes - but it’s full of practical examples and written in a way that speaks to non-engineers (like bureaucrats). If you are a non-technical person handling software stuff, this article should definitely be high on the reading list.

The author seems like an unknown in the software development world, but they’re one of the managers for Singapore’s fairly successful digital government initiative. So it does feel safe to say they have some experience.

Re: How to Build Good Software

#30

Post by jrumbut »

unityByFreedom wrote: post #23
jrumbut wrote: post #13

I thought "what a bold title, if someone's figured it out we can just close HN" and upon reading, hey it's not far off. The following is a wonderful point I have hardly ever heard said directly: "The main value in software is not the code produced, but the knowledge accumulated by the people who produced it."

weird, I've heard it said frequently for decades in various forms, "value your knowledge workers" "your employees are your most valuable asset" Some companies don't treat employees well, and some employees at good companies feel they are not treated well enough If the above quotes do not strike a chord with you, you might just be a software engineer who thinks you're more important than non-SEs.

The difference, for me, is that neither of those quotes explain why you should value knowledge workers or why employees are valuable (maybe hiring is expensive, maybe turnover reduces morale, etc), nor do they suggest the mechanism that creates this value.

I'm sure another author has put the same sentiment out there before, but it's not every day I see such a nice phrasing of it.

Post reply on HN