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

31–40 of 247 posts

Re: How to Build Good Software

#31

Post by nordsieck »

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…

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

> Unfortunately, it appears that the "free love" phase of software engineering is coming to an end, as society now relies more and more on software and major tech players for life and safety. It's starting to get real for software engineering.

Software will always be a spread of reliability requirements, from pacemakers on one side to excel reports on the other. Part of being a responsible user is choosing software with the right balance of economics and reliability for the job.

Re: How to Build Good Software

#33

Post by onion2k »

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

One of my professors condensed that point into something I thought was clever: "Software engineering is the distilling of ambiguity". I think about that whenever I get frustrated about a vague spec or lack of details. It's the job!

"Software engineering is the distilling of ambiguity"

I hope he meant separating out the ambiguity rather than concentrating it. :)

Re: How to Build Good Software

#34

Post by lifeisstillgood »

>>> The hard limit to system complexity is not the quantity of engineering effort, but its quality.

This article is full of good ideas, an antidote to creeping corporate take over of software projects - make this required reading for software projects.

Re: How to Build Good Software

#35

Post by lifeisstillgood »

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

It's not that they have the knowledge but that the knowledge is now encoded in software and available to anyone else - software shares knowledge without the users having to learn it (for example having to learn which five systems need to have their names enters in order to pay their parking fine

Re: How to Build Good Software

#36

Post by hguant »

onion2k wrote: post #33
civicsquid wrote: post #18

Earlier quoted context omitted.

One of my professors condensed that point into something I thought was clever: "Software engineering is the distilling of ambiguity". I think about that whenever I get frustrated about a vague spec or lack of details. It's the job!

"Software engineering is the distilling of ambiguity" I hope he meant separating out the ambiguity rather than concentrating it. :)

I can see it working both ways - in many cases, I'd like my ambiguity distilled down to one specific point, while the rest of the project deals with lower specific ambiguity (where ambiguity in my mind is equal to "is this thing possible").

Re: How to Build Good Software

#37

Post by pmontra »

Hiring the best engineers, technically-wise, is a good thing but it's not enough. In my experience it's better to hire somebody with a previous experience in the domain. Somebody that already built something similar or related. Those engineers will ask the right questions, make the customer think about the system in the right way, not lose time on worthless details. Even if the implementation is not shiny it will be working. It beats shiny but misguided. And if you can find great engineers with great skills, that's even better.

Re: How to Build Good Software

#38

Post by lifeisstillgood »

Years ago I wrote http://oss4gov.org/manifesto saying that governments needed to not only embrace OSS but that it is the only moral option to take.

Now we have government digital systems leading the charge across most western countries, and we have excellent polemics like this. I am just so happy to see this level of insightful ness at top levels of government.

I am so glad they listened to me :-)

Post reply on HN