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

191–200 of 247 posts

Re: How to Build Good Software

#191

Post by carapace »

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?

Re: How to Build Good Software

#192

Post by eropple »

erikpukinskis wrote: post #168
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…

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.

1) In the Hermes Conrad sense, this is technically correct.

2) In my experience, this basically never happens.

Your comment encapsulates a lot of what I have come to call "Scrumbutt." It's Scrum, but. And while I have no idea if it's intended on your part, the sentiment is a fantastic way for a Scrum consultant--only some shade thrown; I've been a "DevOps consultant" before, after all--to come in and pull from deep in their Scrumbutt something to the effect of "you're doing it wrong, Scrum has not failed, you have failed Scrum."

Within epsilon of nobody does Scrum "as prescribed"--because the amount of responsibility that must be undertaken at all levels is virtually impossible to get full buy-in on--and as such the boil on our collective behind that it is persists because criticism is immediately bedeviled by Scotsmen of unknown provenance.

Re: How to Build Good Software

#194

Post by mjlangiii »

madeofpalk wrote: post #123
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…

> They consider the User Stories + the code to be everything you need If you have sufficiently detailed user stories, they can be.

The user story is a promise to have a conversation. I think that is usually well understood. From there I think you can fall into two camps: that conversation should result in a Jira/whatever ticket with all the requisite documentation for an agile team versus that conversation IS the essential information required to properly build the expected valuable working software.

Back to the question - what do you do about poor knowledge transfer in a project? I think a moderate de-emphasis on thinking of the user story text and the additional info like acceptance criteria etc. as self-sufficient documentation and adding more emphasis on that close relationship between developer, user, and maybe a tester, can help fill in big knowledge gaps.

Re: How to Build Good Software

#195

Post by notabee »

Aeolun wrote: post #143
matz1 wrote: post #127

Earlier quoted context omitted.

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.

This is such a critical point. So many problems that plague the industry tie back to this. Lack of company investment in juniors leads to greater job hopping, which leads to building things based on bleeding edge fads to pad resumes, which leads to ever increasing title inflation, NIH syndrome, or cargo culting, which leads to the brutal churn that most everyone hates and wastes tons of man hours instead of just maintaining and improving existing software and teams.

Re: How to Build Good Software

#196

Post by amoitnga »

jshowa3 wrote: post #158
siempreb wrote: post #102

> 3. Hire the best engineers you can. This is where most companies fail. Yes, they do want the best developers, but for the budget of an average junior/medior dev. For some reason most companies/managers I worked for do not understand the financial impact of a not so good developer. Or the other way around; they fail to value the best developers and are unable recognize them. I've worked for plenty companies where th…

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.

Re: How to Build Good Software

#197

Post by bcrosby95 »

roland35 wrote: post #147
abdullahkhalids wrote: post #116

Earlier quoted context omitted.

> 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 ;)

I use this rule for introducing abstraction: don't do it unless you have at least 3 different use cases you're abstracting, and the test suite doesn't count.

Re: How to Build Good Software

#198

Post by vharuck »

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…

It's surprising that wasn't being done in the first place. I used the Warcraft 3 map editor, and it was simple to include references to attribute values in an object's description. Don't know why the DotA2 team didn't port that feature over when moving to the new engine.

Re: How to Build Good Software

#200

Post by frobozz »

goatinaboat wrote: post #71
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…

prefers working code over comprehensive documentation This is funny because “working code” might just mean that it doesn’t crash. But does it actually do what it’s supposed to do or does it reliably deliver the wrong results? How would you know without documentation? The software in the Therac didn’t crash, it quite reliably killed people with its “working code”.

I can't picture a single scenario in which "doesn't crash" is the sole criterion by which code is evaluated as "working"
Post reply on HN