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

231–240 of 247 posts

Re: How to Build Good Software

#231

Post by icebraining »

bsder wrote: post #218
solveit wrote: post #65

Earlier quoted context omitted.

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?

I replied that way because, if we moved this to a tech subject, people here would be horrified at your definition of "effective". If someone produced an insulin pump that you implanted, worked perfectly for life, but killed 1 person in 1,000 randomly, people would be screaming for the head of the CEO of that company rather than calling it "effective".

But that wouldn't be effective because it's random, not because it kills people. A better analogy is if the pump worked perfectly, but killed anyone who the CEO disliked. That would be effective, yet monstrous.

Effective just means it achieves the intended outcome, it's not a value judgment on the goodness of that intention.

Re: How to Build Good Software

#233

Post by oblio »

dnh44 wrote: post #201
amoitnga wrote: post #196

Earlier quoted context omitted.

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.

He's too small and his defense contribution is too low. You'd just chuck 11 prime Yaya Toures at him and watch them dominate the game :-)

Re: How to Build Good Software

#234

Post by jkepler »

Viliam1234 wrote: post #220
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…

> Does anyone have any suggestions on how to fix this? Have a product wiki (e.g. MediaWiki). Have documentation in source code that compiles to HTML code, which can be linked to/from the product wiki (e.g. JavaDoc in Java, Natural Docs for languages that do not directly support compilable documentation). Make building and publishing this documentation a part of the continuous integration. When you have this, make it…

> Have documentation in source code that compiles to HTML code, which can be linked to/from the product wiki (e.g. JavaDoc in Java, Natural Docs for languages that do not directly support compilable documentation). Make building and publishing this documentation a part of the continuous integration.

Are you referring to something like Knuth's Literate Programming (en.m.wikipedia.org/wiki/Literate_programming)? As a non-professional who's learning to develop on the side, something that follows more of a natural language approach appeals to me, as sometimes I have a few months between working on my project, and comments on my source code help me not to forget why I do certain things in the code. However, I'm not doing Literate Programming, just python with comments.

Re: How to Build Good Software

#235

Post by jkepler »

einhverfr wrote: post #108
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…

My experience is you want to move fast by reusing good software. This means that well understood components should be well engineered and documented components, while poorly understood problems might reserve documentation for the future. Agility requires a stable foundation. And a lot of places forget that.

Isn't this the old Unix tools idea, where programs are tools that ideally do one thing well, and with good inter-program communications developers can combine basic tools to build more complex programs?

Re: How to Build Good Software

#236

Post by einhverfr »

jkepler wrote: post #235
einhverfr wrote: post #108

Earlier quoted context omitted.

My experience is you want to move fast by reusing good software. This means that well understood components should be well engineered and documented components, while poorly understood problems might reserve documentation for the future. Agility requires a stable foundation. And a lot of places forget that.

Isn't this the old Unix tools idea, where programs are tools that ideally do one thing well, and with good inter-program communications developers can combine basic tools to build more complex programs?

This was also the original idea of Object Oriented Programming before people thought the real world was a good analogy.

Re: How to Build Good Software

#238

Post by jshowa3 »

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.

To go further, it reminds me of the movie Money Ball.

Re: How to Build Good Software

#239

Post by MyNameIsFred »

Viliam1234 wrote: post #221
dkersten wrote: post #150

Earlier quoted context omitted.

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…

> I've come across the "documentation becomes quickly outdated" argument a lot Me too, but I still feel that saying "documentation quickly becomes outdated" and refusing to write any, is not that different from saying "software quickly becomes full of bugs" and refusing to write unit tests. Yes, if you believe that something is doomed, and therefore you refuse to even try, it becomes a self-fulfilling prophecy. Yes,…

Yes, thank you. A mindset which thinks that documentation is wasted due to a need to constantly update, is cousin to the mindset which thinks that software, once written, is a purchased asset which needs no further attention nor maintenance.

Re: How to Build Good Software

#240

Post by crimsonalucard »

carapace wrote: post #217
crimsonalucard wrote: post #210

Earlier quoted context omitted.

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

Have you read "Introduction to Cybernetics" by Ashby? (PDF available here: http://pespmc1.vub.ac.be/ASHBBOOK.html ) Cybernetics might be the "missing link" for what you're talking about.

I didn't dive to deep into this so I could be wrong but this looks like control theory with elements of category theory.

I'm looking more for a theory of modules and relationships. Something that can formalize the ways we organize code.

Post reply on HN