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

121–130 of 247 posts

Re: How to Build Good Software

#121

Post by madeofpalk »

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…

> Ideally it should be in version control and be generated from the code, because then it's less likely to go out of date

Not always - when you want to document the requirements (in whatever format), having them be separate from the code is often a plus. The code might implement the requirements incorrectly, so being able to recognise that is important.

I find this very similar to writing tests that are separate from your implementation. In fact, Cucumber/BDD tests try to make product requirements executable to validate the software has been written correctly to meet the requirements.

Re: How to Build Good Software

#122

Post by somtum »

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…

How does Millet and Tune's DDD book compare with Eric Evans? Are they both worth reading?

Re: How to Build Good Software

#123

Post by madeofpalk »

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…

> They consider the User Stories + the code to be everything you need

If you have sufficiently detailed user stories, they can be.

Re: How to Build Good Software

#124

Post by mikekchar »

irishsultan wrote: post #67
JohnBooty wrote: post #61

Earlier quoted context omitted.

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. My solution to this is old and fairly unpopular, but I stand by it: anything in the codebase that's not obvious to a new maintainer should have a brief, explanatory code comment. Generally, this falls into two categories…

While I still would add a comment about the why, your last bit of code probably should be written without magic constants. # Some countries have sales tax rules dependent on the day of the week return nil if country_code==KERPLAKISTAN and day_of_week==MONDAY The exact comment here could probably be more specific (e.g. where do you find these rules), but it also most likely shouldn't repeat the code (and the code shou…

If you do the substitution as you suggest and then add a unit test, then you have something ;-) Something on the lines of "describe countries with sales tax dependent upon the days of the week => Kerplakistan doesn't have sales tax on Mondays" So now it's self documented and self testing.

But I agree with your statement that there should be a pointer to the business rules somewhere. Otherwise it's difficult to have a meeting with the business side and ask, "Has anything here changed?" I think that's the biggest thing people miss out -- It's not that hard to find the thing in the code if things change. It's super hard to make sure you are on top of all the business requirement changes.

Re: How to Build Good Software

#125

Post by arethuza »

irishsultan wrote: post #67
JohnBooty wrote: post #61

Earlier quoted context omitted.

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. My solution to this is old and fairly unpopular, but I stand by it: anything in the codebase that's not obvious to a new maintainer should have a brief, explanatory code comment. Generally, this falls into two categories…

While I still would add a comment about the why, your last bit of code probably should be written without magic constants. # Some countries have sales tax rules dependent on the day of the week return nil if country_code==KERPLAKISTAN and day_of_week==MONDAY The exact comment here could probably be more specific (e.g. where do you find these rules), but it also most likely shouldn't repeat the code (and the code shou…

But don't do what one memorably awful project I had to maintain did - to use that example they would have done:

country_code==FIFTY_FIVE and day_of_week==ONE

Re: How to Build Good Software

#126

Post by arethuza »

madeofpalk wrote: post #123
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…

> They consider the User Stories + the code to be everything you need If you have sufficiently detailed user stories, they can be.

When does a "sufficiently detailed user story" become "documentation"?

Re: How to Build Good Software

#127

Post by matz1 »

lelima wrote: post #119
siempreb wrote: post #102

> 3. Hire the best engineers you can. This is where most companies fail. Yes, they do want the best developers, but for the budget of an average junior/medior dev. For some reason most companies/managers I worked for do not understand the financial impact of a not so good developer. Or the other way around; they fail to value the best developers and are unable recognize them. I've worked for plenty companies where th…

>"3. Hire the best engineers you can." If every single company wants that, where is he space to grow and learn from mistakes? Maybe I'm wrong but I think those "mediocre dev's" learned a lot building a big app from scratch, solving bugs and refactoring.

They can learn them on their own time outside of work.

Re: How to Build Good Software

#128

Post by ValentineC »

solveit wrote: post #65
bsder wrote: post #54

Earlier quoted context omitted.

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.

I don't understand the point of replying like this. Clearly we agree that the Singaporean government is very good at getting things done, and we agree that the things it wants to get done are horrible. Why are you speaking as if our opinions differ? Why manufacture conflict where none exists? Is calling something a quasi-Orwellian dystopia now too subtle an expression of disapproval?

> Clearly we agree that the Singaporean government is very good at getting things done, and we agree that the things it wants to get done are horrible.

Singaporean here. The government's mainly effective for tasks that are on a happy path. If your particular case falls through the cracks, it often takes phone calls, printing, postage, and weeks or months of waiting to get stuff done.

(Personal experience trying to get business stuff done not as a Private Limited company.)

Re: How to Build Good Software

#129

Post by whynotminot »

matz1 wrote: post #127
lelima wrote: post #119

Earlier quoted context omitted.

>"3. Hire the best engineers you can." If every single company wants that, where is he space to grow and learn from mistakes? Maybe I'm wrong but I think those "mediocre dev's" learned a lot building a big app from scratch, solving bugs and refactoring.

They can learn them on their own time outside of work.

This is just an awful, awful mindset.

If you want great devs, you're going to have to invest in junior devs, and you're going to have to expect them to be learning at work. This is also why the best use of your senior devs is as mentors to your less experienced ones.

Re: How to Build Good Software

#130

Post by rfrey »

exhaze wrote: post #94
barrkel wrote: post #82

Earlier quoted context omitted.

The "but" negates any disapproving effect it may have had, because structurally the latter part acts as a justification for tolerance. "The tool is squeaky but it gets the job done" - you wouldn't expect the speaker to do anything about the squeaks. Squeaking is tolerable. "The tool does the job but it's squeaky" - you would expect the speaker to do something about the squeaks. Doing the job isn't good enough. Your c…

Comments like this are part of the reason why people like Sam Altman stopped posting here. Can you just give the poster the benefit of the doubt that they just admire the efficiency of the Singaporean government, not that they're endorsing authoritarianism as long as it's effective?

>Can you just give the poster the benefit of the doubt

Perhaps you should do the same for barrkel? I read your parent as a simple explanation to solveit why their comment may have been misconstrued by bsder -- a question solveit directly asked.

Post reply on HN