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

141–150 of 247 posts

Re: How to Build Good Software

#141

Post by spuz »

arethuza wrote: post #125
irishsultan wrote: post #67

Earlier quoted context omitted.

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

But what if the definition of 55 changes? You'll be glad to have your table of constants then.

Re: How to Build Good Software

#142

Post by Ma8ee »

ikll wrote: post #113
Ma8ee wrote: post #87

Earlier quoted context omitted.

Anyone know how to demonstrate this to management? I’m quite certain that my boss think I’m a crappy developer, because I usually take longer than other to produce the same amount of code. But I’ve reduce the amount of code we need to write with three quarters, but that is harder to demonstrate.

Reducing the amount of code shouldn't be the end goal, but a way of increasing quality. You should seek to demonstrate instead that you're making software that is more malleable, has less bugs, is easier for new hires to understand, is easy to add new features, etc.

Of course it is not an end goal. But a quarter as much code has (in general, everything else equal) a quarter as much bugs, a quarter of the amount of code to read and understand for new hires a quarter as much code to take into account when adding new features. But none of these things are easy to measure or demonstrate. It is just easier to see that Ma8ee took 1.5x weeks to write 10,000 loc while other developer wrote 40,000 loc in x weeks.

Re: How to Build Good Software

#143

Post by Aeolun »

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 mindset is what leads to utterly incapable people being hired as seniors. If nobody is willing to hire junior or medior developers, then naturally everyone starts calling themselves senior.

Re: How to Build Good Software

#144

Post by Dumblydorr »

steventhedev wrote: post #138

Regarding "Seek Out Problems and Iterate", it's a bit of an understatement how important this is. I've invested a lot of time helping my coworkers understand the distinction between tasks and problems. The end goal being only tracking problems in the ticketing system. It's not easy to do this and it takes constant effort, but it pays off very quickly. I've yet to see a real "problem" ticket stay unresolved for a long…

Can you explain the 3pm on Tuesdays issue? My sister works for LLS and she said their servers get very slow at a precise time every Tuesday. Not saying it's the same bug, but what was the solution in your specific case?

Re: How to Build Good Software

#145

Post by roland35 »

ptero wrote: post #131
PaulRobinson wrote: post #50

Earlier quoted context omitted.

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

> Documentation is essential. How things work is an important thing to document. I agree with this 100%. However, to be useful it needs to hit the right level of crudity. For most projects, a short ( It is best when this exists as a standalone document which is a required reading for any new developer. After this they can look at module descriptions, function docs, code, etc. and understand how to make sense of it an…

I think there is room for this to be two documents if a project is large enough - one which resides inside source control which explains the design and how it works, and one which is external (sometimes managed by corporate level document control) which explains the "so what", including top level requirements and so forth.

These could be just one document if the project is small enough.

Re: How to Build Good Software

#146

Post by _57jb »

majewsky wrote: post #89
fsloth wrote: post #78

Earlier quoted context omitted.

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.

When mcnichol said "make this its own article", they probably meant to submit the link to HN as its own submission, not to blog about it.

Yeah, that's what was meant. Totally agreed with the statement above this one, it reads well.

Re: How to Build Good Software

#147

Post by roland35 »

abdullahkhalids wrote: post #116
PaulRobinson wrote: post #50

Earlier quoted context omitted.

"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 Interestingly, this has been a big point of discussion in the Dota 2 playerbase. Dota 2 is one of the most complex games ever created and it rapidly changes on the order of days or weeks. At one point, the in-game descriptions of spells were months or years out of date because they were being upda…

This is a good example of a general rule of thumb I learned, if you need to do something once or twice do it by hand, but if you do something three or more times make it a function! Looks like Dota 2 updated their spells a few more than 3 times ;)

Re: How to Build Good Software

#148

Post by zeckalpha »

> Software has characteristics that make it hard to build with traditional management techniques; effective development requires a different, more exploratory and iterative approach.

Or the management techniques considered “traditional” are overlooking a century of iterative development outside of software. See Deming.

Re: How to Build Good Software

#149

Post by codetrotter »

Dumblydorr wrote: post #144
steventhedev wrote: post #138

Regarding "Seek Out Problems and Iterate", it's a bit of an understatement how important this is. I've invested a lot of time helping my coworkers understand the distinction between tasks and problems. The end goal being only tracking problems in the ticketing system. It's not easy to do this and it takes constant effort, but it pays off very quickly. I've yet to see a real "problem" ticket stay unresolved for a long…

Can you explain the 3pm on Tuesdays issue? My sister works for LLS and she said their servers get very slow at a precise time every Tuesday. Not saying it's the same bug, but what was the solution in your specific case?

The next sentence suggested that the cause of the problem in this probably hypothetical situation might be “a cronjob kicking off and hogging disk IO for a few minutes”.

So in that case, I guess either run the job with a lower priority and see if that helps, or execute the job more often so it doesn’t have to catch-up all at once one time per week, or rewrite it so that it performs I/O with smaller chunks of data at a time and sleeps for a little while in-between reading or writing chunks of data. Basically, do something so that you no longer have this one huge job consuming all of the IO bandwidth for several minutes every week.

Re: How to Build Good Software

#150

Post by dkersten »

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…

Many years ago, I worked for a company where we were writing complex distributed telecom software and they had a wiki for documenting the system. I spent a few weeks meticulously documenting everything I did and anything that was touched by it (including defining all of the industry jargon and such). It was a great way to get a quick understanding of any part of the system, but I was the only person keeping it up to date so after a while I ran out of steam and stopped doing it. :(

I've come across the "documentation becomes quickly outdated" argument a lot, but nobody has ever been able to suggest a good alternative. The best I've found is to write design logs for proposed changes (which you then let other team members/stakeholders can review/comment on before it gets implemented) and decision logs for any decisions that are made. This way, them going out of date is expected and ok, as they become a history of ideas and decisions with their context and outcomes laid out. You don't necessarily have a snapshot of "the system right now" but you have a log of all the ideas and decisions that lead up to the current system.

Post reply on HN