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

201–210 of 247 posts

Re: How to Build Good Software

#201

Post by dnh44 »

amoitnga wrote: post #196
jshowa3 wrote: post #158

Earlier quoted context omitted.

I've worked for companies where supposed senior devs write a massive amount of code without even the slightest indepth thought because they think they know everything. Then the project turns out to be months late, even though I called the timeline of the project virtually unfeasible, and we have to go back and make several changes that could've been caught early on with a better strategy. The problem with hiring the…

Agree. sports analogy follows. it won't help you to have 11 'Lionel Messi's on your team. good compatibility among players is much more preferable. It's probably better to have small robust teams that can work together, ppl who are avg in most required areas and are rockstars in certain specific ones.

If you had written any other athlete I would agree.

But in this case I think 11 Messi's would win everything there is to win in football for a decade straight.

Re: How to Build Good Software

#202

Post by kickopotomus »

richardwhiuk wrote: post #165
JohnBooty wrote: post #152

Earlier quoted context omitted.

That's a very good point. Avoiding magic numbers would have removed the need for an explanatory comment in my example.

Comments are often a code smell. In lots of examples, better variable naming, breaking something out into a function, or constants often reduces the need for a code comment.

I disagree. Code ages and people move on. 2 years down the line some new guys are maintaining the code base. Some new guy is testing the system and notices that sales tax values seem to be "strange" for Kerplakistan on certain days of the week so they create a ticket for it. Then that goes through the typical pipeline. Another member of the team gets assigned the issue and looks into it. They come across the line:

  return nil if country_code==KERPLAKISTAN and day_of_week==MONDAY
Hmm.. Well that's strange. I don't have a background in Kerplakistan monetary policy so I don't know why we aren't assessing sales tax on Monday. Perhaps Kerplakistan is a special case. Is that being handled somewhere downstream? Then 1-2 hours later, after shuffling through source and eventually just Googling Kerplakistan sales taxes, you discover what someone found out 2 years ago when they wrote that line. Now you resolve the ticket and move on with your day but you just wasted a couple man-hours on a non-issue that could have been resolved instantly from a code comment.

Comments are as much for the next guy as they are for you.

Re: How to Build Good Software

#203

Post by AnimalMuppet »

einpoklum wrote: post #109

> Software has characteristics that make it hard to build with traditional management techniques Perhaps some software development techniques would work though... > The main value in software is not the code produced, but the knowledge accumulated by the people who produced it. Those people go on to work on other things or for other organization. So, while that statement might have some truth to it, it's still the ca…

> > Software has characteristics that make it hard to build with traditional management techniques

> Perhaps some software development techniques would work though...

As you go up the management chain, you usually run into some layer where people are traditional managers, who want to run a software project like a traditional project. And behold, you're at this problem. Saying "software development techniques would work" is useless unless you can get those managers to change. And when you get them to change, the problem moves up one layer.

Re: How to Build Good Software

#204

Post by kgwxd »

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…

The first place I worked as a software dev had an owner that would explain everything about the business and the problems to me in very good detail. He would just stop by my desk whenever he thought of something he thought might be good for me to know. Eventually understanding the business became just as interesting as the coding. These days, I hate getting a task without knowing the business side of things or not being able to discuss it directly with the person that does.

Re: How to Build Good Software

#205

Post by drderidder »

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…

I think this is also known as the fallacy of the fungible engineer / myth of the interchangeable programmer.

Re: How to Build Good Software

#206

Post by skybrian »

dkersten wrote: post #150
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…

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…

Yes, I agree that treating most documentation as project history is the practical way to go.

Another thing that helps is to write good commit messages giving the business context for a change. When code is reviewed, the commit messages should be reviewed as well. If they don't agree then that's a problem.

Re: How to Build Good Software

#207

Post by snovv_crash »

arethuza wrote: post #151
spuz wrote: post #141

Earlier quoted context omitted.

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

The project also defined HTTP, COLON, SLASH, WWW and DOT so that you would have: string url = HTTP + COLON + SLASH + SLASH + WWW + DOT ... I swear I'm not making this up....

Well at least a typo sould give a compile time error for some subset of typos.

But in the trade-off in code readability was probably the cause of many other mistakes, so probably ended up further behind.

Re: How to Build Good Software

#208

Post by k__ »

"Software Is about Developing Knowledge More than Writing Code"

This is also the real problem with vendor lock-in.

You are more often locked in by the knowledge of your employees than by your tech stack.

Re: How to Build Good Software

#209

Post by TeMPOraL »

base698 wrote: post #188
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…

Why not: return nil if country_code==KERPLAKISTAN and day_of_week==MONDAY Then you don't need comments and the sync problem goes away?

Except this doesn't retain the crucial information: why? It looks arbitrary. The thought that "some countries have sales tax rules dependent on the day of the week" may or may not be obvious from the context. At the very least, the comment pins a point in the space of all possible reasons for that piece of code - with it, you know it's related to sales tax and week days, and isn't e.g. a workaround for the bug with NaNs in tax rates that you saw on the issue tracker last week.

Re: How to Build Good Software

#210

Post by crimsonalucard »

carapace wrote: post #191
crimsonalucard wrote: post #15

Nice Post. But everyone needs to understand something. Even if you follow these principles to the letter T, you can still produce very bad software. In fact you can also find many cases where people did the exact opposite of what this guy said and still produced great software. I'm sure many people can name examples of software that just came together out of blind luck. Why? Because there is no formal definition for…

So you're not talking about "formal methods"? https://en.wikipedia.org/wiki/Formal_methods The Applied Category Theory folks have some very interesting stuff, like Categorical Query Language. https://www.appliedcategorytheory.org/ https://www.categoricaldata.net/ But it sounds to me what you mean is more like if "Pattern Language" was symbolic and rigorous, eh?

Yes, this is exactly what I mean. Though I feel patterns can be formalized within thr framework of category theory.
Post reply on HN