[collyw]

"No. Good software comes from understanding the needs of your customers and meetings those needs. Shitty developers have and will create awesome products just because they know what the users want and need."

Depends what you class as "good software". My colleague left some code which "worked" and "met the needs" (at the time). I made a small change to the database it interacted with and it fell over. I had to go in a debug it, but it was so badly written I had to completely refactor it just to debug it properly.

So her software met the needs, my rewrite of it met the needs, and has been far more reliable and maintainable. I would say that is better software.

[hpaavola]

Of course technically better implementation is better if the only thing that changes is the technical quality of the implementation.

But it does not follow that doing good software is a technical challenge. It does not matter how fast your algorithm is if nobody wants the results that it spits out.

Defining good software is really hard task, but in general what I mean by it is that good software increases the well-being of its users. Yes, one aspect of that is the technical quality of the implementation.

[usea]

What happens when the needs of the customers or users change? What happens when your understanding of their needs was imperfect and needs to be updated? Is the software that met the old needs still good? Was it ever good?

What happens when the software could only ever meet the old needs, but is impossible to update to meet the new needs? Was it ever good?

Needs change. The ability for software to be altered to meet evolving needs is not simply a "technical quality of the implementation." It doesn't just have a faster algorithm. It's better software.

[hpaavola]

I'm not sure what part we disagree here. Yes, technical quality matters. But it matters way less than delivering something that users need. And yes, better technical quality ceteris paribus equals better software.

[usea]

We disagree whether meeting the needs of your users is a technical challenge. The ability for software to meet changing needs is a technical quality of the software.

[hpaavola]

The ability for software to meet the needs is mostly a technical problem. After all, it is a feature of the implementation. But that is not the bigger problem. The bigger problem is to figure out the needs and that is not a tecnical problem.

[raverbashing]

Good software is the one that fulfills a need and pays the bills, period.

The Moon Lander software on the Apollo spacecraft probably had several defects, was unmaintainable, but it got the job done several times.

MS-DOS had several defects, was more maintainable than the above software sure, but it transformed MS.

Sure, it is better when the software is maintainable, more flexible, etc, and I don't advocate against it. What I do advocate against is overthinking all of this and not shipping.

[enraged_camel]

It was your fault. You made a modification to a production database without understanding the full repercussions. You brag about how your refactoring made her software better, but you are ignoring the fact that you got into that mess because of a failure to follow best practices and common sense.

[collyw]

Sure it was my fault she used functions within functions because she didn't know how to understand Pythons module system. It was my fault she had big nested hashes without any comments to explain the structure. It was my fault she had two variables "Indexes" and "indexes" in the same function. I must be the shitty coder, not her....

I at least try and make my code maintainable.

[enraged_camel]

She may be a shitty coder [1]. But her code worked at the time she wrote it, right? And it only broke after you went in and fiddled with the database without first checking to see what systems and programs were using that database and how your changes would affect those systems and programs, right?

[1]Or she may not be. Often times when you develop a system or even write a piece of code, you operate under certain constraints that might make it impossible to make it fool-proof. You may also not have the opportunity to come back and refactor it later. Maybe that was the case when she wrote her code. You may have had the time to debug what she wrote and even re-write it from scratch. She may not have had that luxury.

Heck, maybe she wasn't even a professional programmer. Maybe she had just taught herself some basic programming and wanted to apply it to the job to add value to the company and succeeded in doing so, and she had no idea that some douchebag would come in at a later date, break her program and then blame her for being a shitty programmer. The point is: her code worked at the time she wrote it. It was you who broke it. End of story.

[watwut]

What best practices do you imagine him not to follow?