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

91–100 of 247 posts

Re: How to Build Good Software

#91

Post by joes223 »

koevet wrote: post #66

The article lists the characteristics of a good engineer: * has a better grasp of existing software they can reuse * (has) a better grasp of engineering tools, automating away most of the routine aspects of their own job * design systems that are more robust and easier to understand by others * the decisions they make save you from work you did not know could be avoided I obviously concord with the analysis (not sure…

It's not a paradox because the statement that the interview processes don't evaluate candidates is false. It's proven that this particular interview format has a very high correlation with the future candidate's performance.

Re: How to Build Good Software

#92

Post by al_form2000 »

crimsonalucard wrote: post #62
al_form2000 wrote: post #26

Earlier quoted context omitted.

We know a great deal about dynamics,kinematics, thermodynamics and generally the physics that governs car components, yet we are a long way from an algorithm that applied to a car will produce a better car. My guess is that doing that for software is as hard, if not harder. Also the sentence 'algorithms that applied to algorithms produce a better model' has a strong smell of halting problem, at least to this nose.

I get where you're coming from. I think your intuition is off. Intuitively, software can be modeled as a graph of modules with lines representing connections between modules. An aspect of "good software" can be attributed to some metric described by the graph, let's say the amount of edges in the graph... the less edges the less complex. An optimization algorithm would probably take this graph as an input and output…

The halting problem bit is a shower thought with no supporting evidence whatsoever, so your complexity lowering scenario may well be doable. However, paring complexity is a strictly developer-side measure of goodness (that is assuming that the low complexity result is still readable, maintainable...) - we can agree that reducing bugs is also a very good user side metric, but that tells only a (little) part of the story.

In my experience, developer-side evaluation has a very low impact (I was about to write: zero) on the perceived and actual goodness of the software itself. Which is tied mostly to factors such as user experience, fit to the problem it was designed for and to the organization(s) it is going to live in (user experience again). These properties do not strike me as amenable to algorithmic improvement, no more than "pleasant body lines and world class interiors" in the original car analogy. But they are a (big) part of good software design, besides being the 'raison d'etre' of the darned thing to begin with.

But let's forget cars, as hard as it is. Few months ago HN was running the story about developing software in Oracle. Now, Oracle may be by now a little soft around the edges, but I think that most would agree that it has been setting the standard for (R)DBMS for decades. Success may not on itself be the tell-all measure of software goodness, but the number of businesses that have been willing to stake the survival of their data on Oracle is surely a measure of its perceived goodness (as that other elusive factor - hipness - tends not to be paramount in the DBMSs business).

The development side story, taken as face value, was pure horror (https://news.ycombinator.com/item?id=18442941). Everything in it spoke bad, outdated, rotting design. The place must be teeming with ideas on how to improve just about everything in that environment. And yet if that came to be, maybe by some nifty edge pruning algorithm, it would do nothing to improved the goodness-to-the-world measure of the software, not until the internals' improvement translated to observables in the user base experience.That type of improvements will still require vaste amount of non-algorithmic design and, in the meantime, a very concrete risk will be run of deteriorating the overall user experience (because ehi, snafus will happen).

This (internals are just a small part of the story) is one of the reasons why so many reimplementations I have seen failed ("ehi, let's rewrite this piece of shit and make it awesome") and the reason because everyone resists the move from IPV4 to IPV6. I could think of many more examples.

Re: How to Build Good Software

#93

Post by tester344 »

acd wrote: post #19

Keep it simple software should be open source. Government software often has similar demands as other countries. Share and reuse. Reusing good modules and software will make the software work. Kiss engineering still works keep it simple stupid. Make it as simple as possible. Simple software and systems are easy to maintain and understand. Use modules as these can be swapped out. Use proven boring technology such as S…

>Government software often has similar demands as other countries.

What makes you think so?

Re: How to Build Good Software

#94

Post by exhaze »

barrkel wrote: post #82
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?

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?

Re: How to Build Good Software

#95

Post by kitsune_ »

dajonker wrote: post #76
kitsune_ wrote: post #40

Except for the 10x myth a fairly good article.

I disagree with that, if you describe it as stated in the article: "Overall, good engineers are so much more effective not because they produce a lot more code, but because the decisions they make save you from work you did not know could be avoided." I've seen plenty of poor decisions that cause 10x the work, and end up with something 10x less maintainable.

I'm not disagreeing with the idea that there is variability in developer productivity. However, quantifying the most productive engineers by throwing around a specific random factor such as "10x" is rather idiotic.

You have entire blog posts by Steve McConnell of Code Complete fame devoted to defending the 10x claim by citing 20 to 50 year old research that shows 5x to 20x differences across certain dimensions and then him falling back to the 10x thing. Not one single sentence where he is being self aware enough to spell out the most likely reason for "10x" being so prominent: 10 is the base of the decimal system and as such psychologically attractive to use.

> Both Steve Jobs and Mark Zuckerberg have said that the best engineers are at least 10 times more productive than an average engineer.

I know I'm venturing into ad hominem territory with this, but first of all: Steve Jobs wasn't a programmer. Mark Zuckerberg, well does he even qualify as a programmer nowadays? How well can he quantify programmer productivity? His decision to use PHP led Facebook to create HHVM and Hack. Is this the 10x developer way?

Anyways, the question to me is: Is it possible for average software engineers to write good software?

Re: How to Build Good Software

#96

Post by 9nGQluzmnq3M »

hnick wrote: post #70
9nGQluzmnq3M wrote: post #14

The article appears to be written by Singaporean prime minister Lee Hsien Loong's son, Li Hongyi. http://theindependent.sg/li-hongyi-singapore-has-a-lot-of-pr...

Now I'm wondering why the children romanized their surname as Li not Lee. I came across this article: https://mothership.sg/2015/03/lee-hsien-yang-reveals-the-sto... > I have taught my children never to mention or flaunt their relationship to their grandfather, that they needed to make their own way in the world only on their own merits and industry.

Singapore's older generations speak/spoke Chinese "dialects" like Hakka (Lee Kuan Yew's heritage), but there has been a massive government-led push towards standardizing on Mandarin as the one true Chinese. Hence Lee Hsien Loong's children all have their names officially romanized in Mandarin pinyin (Li), not Hakka (Lee). The underlying character, 李, is still the same.

Re: How to Build Good Software

#97

Post by JamesBarney »

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…

Haha yeah the number of times I've gotten "Hey someone estimated a task would take 40 hrs on a project you've never seen with libraries you've never touched. mind knocking that out this week?" is astounding.

Re: How to Build Good Software

#98

Post by hnick »

joes223 wrote: post #88
hnick wrote: post #57

This is great. So many quotable quotes. If only we could make it required reading for our clients! This one struck me, because as soon as I read it I knew it was true yet had never considered it: > Most people only give feedback once. If you start by launching to a large audience, everyone will give you the same obvious feedback and you’ll have nowhere to go from there. I've been on both sides of that fence and it ri…

Anonymous feedback (like really anonymous) is the answer. people can't give real feedback and be nice at the same time.

I think feedback fatigue is a real thing though. The comment about only leaving feedback once hit home to me. It's rare I bother reviewing something twice even if asked, and especially if my original round of feedback didn't seem to change anything (which I understand is totally reasonable in many cases, but still a little disappointing).

Re: How to Build Good Software

#99

Post by simonswords82 »

joes223 wrote: post #85
unityByFreedom wrote: post #23

Earlier quoted context omitted.

weird, I've heard it said frequently for decades in various forms, "value your knowledge workers" "your employees are your most valuable asset" Some companies don't treat employees well, and some employees at good companies feel they are not treated well enough If the above quotes do not strike a chord with you, you might just be a software engineer who thinks you're more important than non-SEs.

Employees are not assets because the company doesn't own them.

True but they produce value which goes on to become an asset, in this case the knowledge captured and organised in to software.

Re: How to Build Good Software

#100

Post by hnick »

koevet wrote: post #66

The article lists the characteristics of a good engineer: * has a better grasp of existing software they can reuse * (has) a better grasp of engineering tools, automating away most of the routine aspects of their own job * design systems that are more robust and easier to understand by others * the decisions they make save you from work you did not know could be avoided I obviously concord with the analysis (not sure…

The way I interpreted that last comment was as a counterpoint to the idea that large companies necessarily end up hiring many mediocre employees because the talent pool simply isn't deep enough to stack the deck. Instead of just being happy with what they can get, the big tech companies make it a real challenge to be hired.
Post reply on HN