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

161–170 of 247 posts

Re: How to Build Good Software

#161

Post by _pmf_ »

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…

> This struck a chord with me: "Software Is about Developing Knowledge More than Writing Code"

Managers are very unhappy when I tell them of all the knowledge I've developed.

Re: How to Build Good Software

#162

Post by yowlingcat »

iEchoic wrote: post #159

> Reusing software lets you build good things quickly It also introduces unknown amounts of debt and increases the likelihood that you'll end up with intractable performance/quality/velocity problems that can only be solved by re-writing large portions of your codebase. This can be a dangerous cultural value when it's not presented with caution, which it isn't here. I think it's best to present it alongside Joel Spoe…

Great article. I liked this quote:

```

The best advice I can offer:

If it’s a core business function — do it yourself, no matter what.

Pick your core business competencies and goals, and do those in house. If you’re a software company, writing excellent code is how you’re going to succeed. Go ahead and outsource the company cafeteria and the CD-ROM duplication. If you’re a pharmaceutical company, write software for drug research, but don’t write your own accounting package. If you’re a web accounting service, write your own accounting package, but don’t try to create your own magazine ads. If you have customers, never outsource customer service.

```

This all rings true in my experience. You should write the software that's critical to your core business competency yourself, because the maintenance cost is worth paying if you can achieve better software. But if it's not a core competency and your business isn't directly going to benefit from having best in class vs good enough, then it may be worth outsourcing.

Re: How to Build Good Software

#163

Post by typon »

mappu wrote: post #44
lifeisstillgood wrote: post #21

Earlier quoted context omitted.

Sorry - the son of Singapore's Prime Minister is a Scala Hacker ... I keep on saying that Software Literacy is a real thing. And that this current generation of leaders are like Charlemagne - he was the first Holy Roman Emperor and the last who was illiterate. Interesting to see it in practise

Singapore's Prime Minister prefers C++: https://arstechnica.com/information-technology/2015/05/prime...

> One of them browsed a book and said, 'Here, read this.'" It was a textbook on the Haskell programming language, Lee recounted. "One day that will be my retirement reading."

Even Singapore's PM has to put up with smug Haskell programmers

Re: How to Build Good Software

#164

Post by potta_coffee »

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)

It could be worse, the product owner could be killing the project by their presence instead.

Re: How to Build Good Software

#165

Post by richardwhiuk »

JohnBooty wrote: post #152
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…

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.

Re: How to Build Good Software

#166

Post by 0x445442 »

ak39 wrote: post #133

Building good software requires mainly achieving two things: 1. Making sure what you build is what was really requested (correct), and 2. Making sure what you've built doesn't have a higher running "cost" than the thing it replaced (either manual process or old automated solutions). Everything else, IME, is ancillary. Performance, choice of platform, frameworks, methodology to build, maintainability etc are sub-objec…

I agree with you but what I've noticed is for all the large projects I've worked on it was impossible to get an official answer as to whether or not the whole endeavor had a positive ROI. In fact, with a little back of the napkin math and some knowledge of the project's resource allocation it was obvious in most cases there would not ever be a positive ROI.

Re: How to Build Good Software

#167

Post by rpmisms »

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

Sounds like a PHP codebase I'm currently working in. I shit you not, $LI = '' is in the functions file, along with $LI_END.

Re: How to Build Good Software

#168

Post by erikpukinskis »

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…

In Scrum, you don’t write code based off User Stories. The scrum team agrees to a set of Stories for the sprint, and then the scrum team breaks those stories into a set of Tasks which are the actual work that must be done. The User Stories are just something the product owner uses to show stakeholders that the project was successful.

Re: How to Build Good Software

#169

Post by sethammons »

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…

We create "blueprints" that have system design and goals on new projects and how they fit into the ecosystem. We are supposed to update them after they go into production as things change, but seldom do. Still, going back and reviewing a design document helps.

Re: How to Build Good Software

#170

Post by arethuza »

rpmisms wrote: post #167
arethuza wrote: post #151

Earlier quoted context omitted.

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

Sounds like a PHP codebase I'm currently working in. I shit you not, $LI = ' ' is in the functions file, along with $LI_END.

It was a very enterprisey Java codebase from the bad old days of J2EE - it had somewhere over 30 layers of abstractions between the code in a JSP and a web service call.

[NB 30 isn't an exaggeration - I think the vast team who wrote it were paid by the abstraction or something].

Post reply on HN