Live data from Hacker News

How to Build Good Software

csc.gov.sg

51–60 of 247 posts

Re: How to Build Good Software

#51

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…

> "Software Is about Developing Knowledge More than Writing Code" The company I work for uses Scrum. They consider the User Stories + the code to be everything you need. I struggle with this, but my manager says they don't want to get tied up doing documentation "because it goes out of date". Beside, they are being Agile which "prefers working code over comprehensive documentation". I am wondering what other companie…

> Does anyone have any suggestions on how to fix this?

Not to be rude, but yes: switch employers. This is not something you can fix on the employee level, it is a management issue.

Re: How to Build Good Software

#52

Earlier quoted context omitted.

> "Software Is about Developing Knowledge More than Writing Code" The company I work for uses Scrum. They consider the User Stories + the code to be everything you need. I struggle with this, but my manager says they don't want to get tied up doing documentation "because it goes out of date". Beside, they are being Agile which "prefers working code over comprehensive documentation". I am wondering what other companie…

> Does anyone have any suggestions on how to fix this? Not to be rude, but yes: switch employers. This is not something you can fix on the employee level, it is a management issue.

Yes. I've never seen unenlightened management somehow become enlightened.

Re: How to Build Good Software

#53
> Overall, good engineers are so much more effective not because they produce a lot more code, but because the decisions they make save you from work you did not know could be avoided.

This is spot on, and very much my experience (of the good engineers I've come across).

Kind of : management had planned extensive and painful testing of a component that turned out to be discarded entirely (not because of functionality reduction but because it was actually unecessary).

Re: How to Build Good Software

#54
post #20

Earlier quoted context omitted.

This also very much reads like something from Singapore.

A quasi-Orwellian dystopia Singapore may be, but their government is effective.

Only for certain strained definitions of "effective".

And, if you are on the wrong side, it is very "effective" at ruining your life.

Most of us would take a bit less "effective" in order to avoid that, thanks.

Re: How to Build Good Software

#55

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 develop…

Li Hongyi is the son of Singapore PM Lee Hsien Loong, as well as a deputy director in GovTech Singapore (the Government Technology Agency). (He's also an MIT CS grad, and a past Googler.)

I suppose he wrote this for other people in the Singapore civil service.

Re: How to Build Good Software

#56
post #54
post #20

Earlier quoted context omitted.

A quasi-Orwellian dystopia Singapore may be, but their government is effective.

Only for certain strained definitions of "effective". And, if you are on the wrong side, it is very "effective" at ruining your life. Most of us would take a bit less "effective" in order to avoid that, thanks.

>Only for certain strained definitions of "effective".

Have you compared it to others? Strained is the last word I'd use to qualify how effective it is...

Re: How to Build Good Software

#57
This is great. So many quotable quotes. If only we could make it required reading for our clients!

This one struck me, because as soon as I read it I knew it was true yet had never considered it:

> Most people only give feedback once. If you start by launching to a large audience, everyone will give you the same obvious feedback and you’ll have nowhere to go from there.

I've been on both sides of that fence and it rings true.

Re: How to Build Good Software

#58

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…

So knowledge about:

- the problem you are trying to solve

- how you could solve it

- how you actually did solve it

- which solutions come with which flaes and merits

Re: How to Build Good Software

#60

Earlier quoted context omitted.

> "Software Is about Developing Knowledge More than Writing Code" The company I work for uses Scrum. They consider the User Stories + the code to be everything you need. I struggle with this, but my manager says they don't want to get tied up doing documentation "because it goes out of date". Beside, they are being Agile which "prefers working code over comprehensive documentation". I am wondering what other companie…

"prefers working code over comprehensive documentation" does not mean "don't do documentation". Documentation is essential. How things work is an important thing to document. Ideally it should be in version control and be generated from the code, because then it's less likely to go out of date. It still has problems (What do you do when the code and the documentation disagree? Which is correct?), but they're not as s…

Thanks for the thoughtful response, this is helpful.

> Ideally it should be in version control and be generated from the code ..

May I ask if you have suggestions for tooling to capture the high level documentation. We use javadoc a little, but it seems best for lower level reference. Also for diagrams, like sequence diagram and/or state machines, how do you capture this?

Thanks.

Post reply on HN