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

71–80 of 247 posts

Re: How to Build Good Software

#71

Post by goatinaboat »

clumsysmurf wrote: post #42
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…

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

This is funny because “working code” might just mean that it doesn’t crash. But does it actually do what it’s supposed to do or does it reliably deliver the wrong results? How would you know without documentation?

The software in the Therac didn’t crash, it quite reliably killed people with its “working code”.

Re: How to Build Good Software

#72

Post by unityByFreedom »

jrumbut wrote: post #30
unityByFreedom wrote: post #23

Earlier quoted context omitted.

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.

> neither of those quotes explain why you should value knowledge

I mean, the point of short quotes is to be memorable and get future listeners to hunt for the reason behind them. "The sun will rise tomorrow" may also be meaningless for some people on its own.

Nothing wrong with elaborating on this subject again via a blog post, I was just pointing out to the commenter who's never heard this expressed before that it has a long history, that's all.

Re: How to Build Good Software

#73

Post by ldng »

ivanhoe wrote: post #64
clumsysmurf wrote: post #42

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…

I've been on a couple of projects like that, and in my experience the real reason behind this logic is that manager and product owner this way may make themselves indispensable, they can't ever get fired without practically killing the project (until it becomes completely unmaintainable and slowly dies off)

And then they leave

Re: How to Build Good Software

#74

Post by mrmonkeyman »

PaulRobinson wrote: post #50
clumsysmurf wrote: post #42

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…

I never understood why generated API docs are "documentation". That is source, trivial technical info which is easy to find in the source anyway.

I never got documentation about the thought processes, the iterations, the design meeting, the considerations, etc. Which is way, way more important to understanding a system in context than knowing "convertLinear" takes 2 unsigned ints.

Re: How to Build Good Software

#76

Post by dajonker »

kitsune_ wrote: post #40

Except for the 10x myth a fairly good article.

I disagree with that, if you describe it as stated in the article: "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."

I've seen plenty of poor decisions that cause 10x the work, and end up with something 10x less maintainable.

Re: How to Build Good Software

#77

Post by ikll »

mychael wrote: post #59

This reads like conventional wisdom. No one is going to argue against "Hire the Best Engineers You Can" and "Start as Simple as Possible".

If only.

Industry this days is more about headcount than quality itself. Why hire two good engineers when you can have three mediocre ones for the same price?

On simplicity, common wisdom these days dictate that we should use bloated kitchen-sink backend MVC frameworks that generate dozens of directories after `init`, because supposedly nobody knows how to use routers. Frontend compiler pipelines are orders of magnitude more complex than the reactive frameworks themselves, because IE11. And even deployment now requires a different team or expensive paid services from the get go. We're definitely not seeking simplicity.

The second point is also something that most developers and managers would balk at: "To build good software, you need to first build bad software, then actively seek out problems to improve on your solution". Very similar to the Fred Brooks "throw one away" advice that no one ever followed.

Re: How to Build Good Software

#78

Post by fsloth »

_57jb wrote: post #45
mmatants wrote: post #22

Earlier quoted context omitted.

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

You should consider making this it's own article. "...the designers job is not to pass along "the design" but to pass along "the theories" driving the design. Knowledge of the theory is tacit in owning..." Well said. Thank you!

I would prefer people read the original paper than any second-hand explanation of it. The paper is very readabale and understandable, and is probably relevant as long as into the future as human beings write code.

Re: How to Build Good Software

#79

Post by fsloth »

mmatants wrote: post #22
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

I was about to suggest the same thing. This paper should be mandatory reading for anyone that is professionally involved in a software development project.

Re: How to Build Good Software

#80

Post by tr3ndyBEAR »

clumsysmurf wrote: post #42
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…

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

Get a new manager
Post reply on HN