How to Build Good Software • Hacker News Board

Re: How to Build Good Software

#101

Post by ikll » Mon, Aug 19, 2019, 9:29 AM UTC

jacquesm wrote: post #51

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? Not to be rude, but yes: switch employers. This is not something you can fix on the employee level, it is a management issue.

Sometimes it's even more complex than a management issue.

It might be a team culture or company culture issue, and even radical changes in the management are not enough to fix it.

Re: How to Build Good Software

#102

Post by siempreb » Mon, Aug 19, 2019, 9:33 AM UTC

> 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 they let mediocre dev's build a big app from scratch (including the architecture), in an Agile self managed team.. These are the codebases that always need to be rewritten entirely because they have become an unmanageble buggy mess of bad ideas and wrong solutions.

Re: How to Build Good Software

#103

Post by Oras » Mon, Aug 19, 2019, 9:44 AM UTC

> 3. Hire the best engineers you can.

What is the definition of "best engineers"? Those with extensive experience? those who follow design patterns and coding standards religiously? those who solve algorithms on a whiteboard? I would like to see if there is a definition for this.

I would say build the right culture (collaborative, always learning from mistakes and revise decisions and no blame or pointing fingers).

You can get a bunch of great coders/engineers _who follow code standards, break down codes to zillions of functions/methods ... etc_ but will fail to work together and conflicts will raise quickly.

Re: How to Build Good Software

#104

Post by unicornmama » Mon, Aug 19, 2019, 9:44 AM UTC

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…

Former Googler here.

Google views picking new engineers like picking quality construction metals. In the end, the machine melts you down and hammers you into a pristine cog.

Re: How to Build Good Software

#105

Post by johnfisher57 » Mon, Aug 19, 2019, 9:47 AM UTC

nice one

Re: How to Build Good Software

#106

Post by unicornmama » Mon, Aug 19, 2019, 9:50 AM UTC

After a brief visit and further readings, I’ve learned to admire Singapore’s 1st world transformation. I’m a absolutely in awe that a government body can produce such a high quality article.

Re: How to Build Good Software

#107

Post by einhverfr » Mon, Aug 19, 2019, 9:51 AM UTC

One additional principle is this:

When faced with a standard solution, use a standard component if you can. If you can't use a standard component, build a standard component. Keep your components simple, well-understood, and easy to maintain.

Re: How to Build Good Software

#108

Post by einhverfr » Mon, Aug 19, 2019, 9:55 AM UTC

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…

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.

Re: How to Build Good Software

#109

Post by einpoklum » Mon, Aug 19, 2019, 10:04 AM UTC

> 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 case that the code has to be useful, robust, and able to impart knowledge to those who read it (and the documentation).

> Start as Simple as Possible

That's a solid suggestion to many (most?) software projects; but - if your goal is to write something comprehensive and flexible, you may need to replace it with:

"Start by simplifying your implementation objectives as much as possible"

and it's even sometimes the case that you want to sort of do the opposite, i.e.

"Start as complex as possible, leading you to immediately avoid the complex specifics in favor of a powerful generalization, which is simpler".

Re: How to Build Good Software

#110

Post by meerita » Mon, Aug 19, 2019, 10:14 AM UTC

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…

I've worked in a company where I enforced as a PM to write Technical Document of every project we did along with the PID, the Functional Document (design and interactions). That Technical Document was all about to describe the essentials, and not go deeper into every single class written. It was intended for those developers who wanted to join the team and update that old project. With it was useful document and barely updated.