

How to write good software - theorique
http://www.drmaciver.com/2014/02/how-to-write-good-software/

======
calinet6
Wait, this is just a train of thought... and it's got almost nothing in it.

I'll save you the read: "Good software is produced by teams who represent the
people they’re building software for."

I feel like this has to be backed up by something. I don't feel it's
necessarily true, or even correlated with good software. Some good software
tends to come from teams which have domain knowledge, but good software also
comes from teams where not everyone on the team necessarily does. Sometimes
just the UX team has the domain knowledge, and the programming team knows how
to program really well. Sometimes they're one and the same. The author hasn't
landed on anything here except perhaps "UX process is a relatively important
part of creating good software."

I'll offer a deeper answer.

Good software is created by good process executed by people who understand
both the importance of that process, as well as how to create.

Knowing how to create is step one. You must master the craft of software
first, and find people who also have, or want to.

Good. Now you must understand process. As your software grows, it will cease
to fit inside your head. You have to build systems surrounding your software
that guarantee its quality, and bypass your feeble human limitations.

Good. Now, as your company grows, you must understand people. The
relationships and complex interactions and psychology will cease to fit inside
your head. You have to understand the motivations and limitations of people in
general, and your specific people, and make sure your company aligns them all
in the direction of quality. You must build a company that values quality, and
values the quality process, above all else.

Build an organization which is aligned toward quality, and it will produce
quality software.

I didn't go into enough depth, but this guy did:
[https://en.wikipedia.org/wiki/W._Edwards_Deming](https://en.wikipedia.org/wiki/W._Edwards_Deming)

But yes, for a team of one, it is probably closely aligned with how well you
understand your users.

------
_pmf_
> Anything you do that you did not set out to achieve is achieved by accident

I disagree. Software that incorporates deep domain knowledge often results in
emergent features, i.e. features that offer huge benefits, but that are
essentially free to implement (negligible effort) due to the underlying
design.

------
jonwachob91
You'll have to pardon me for not reading the whole article; but you opened up
saying you've never even followed this process yourself. That's a big red flag
for me.

If history has taught us anything it is that just because it works on paper
doesn't mean it works in reality. 1\. Communism sounds great on paper, but we
know it sucks... 2\. Science works on paper a lot, but experimental physicist
exist because it can't always work. 3\. When Dr. Phil comes out with a weight
loss plan, no one with 2 brain cells believes it actually works (cause ya
know, he never lost weight on it).

4 (and my biggest point). If it's so great why have you yourself been unable
to follow it? Could it be that your process is unrealistically challenging, or
maybe it doesn't account for many real world issues. But I'm willing to bet
that you think you write great software already and don't need to follow your
own guidelines.

The bottom line is that until you become your own activist (meaning you follow
the principals rigidly and write good software) you can't preach it.

You don't see people running around promoting a religion they don't even
follow.

------
dTal
I was expecting a discussion of best practices, but it doesn't actually talk
about how to write good software at all. The title should be "Corporate
incentives sometimes interfere with software engineering best practices when
the software itself is the product". Also, there are a lot of assumptions - I
imagine most technology startups need to write software, but many of them
aren't in the business of selling it.

------
patrickmay
TL;DR: Confusion about code purity not being the only goal for software, blah
blah blah, suddenly a social justice warrior appears!

------
vezzy-fnord
_Consider Linux on the desktop vs OS X or even Windows. Sure, I use and sorta
like it, but I don’t think I could keep a straight face if I tried to tell you
it was higher quality._

I'd honestly want someone to elaborate on this.

Personally, after spending lots of time with GNU/Linux and BSD, I find it
_physically painful_ to use Windows. Even with the existence of alternative
DEs, third-party package managers and whatnot, your entire perception of what
an OS should be simply changes after being exposed to the Unix way and you
never really go back.

~~~
DRMacIver
For context, my normal desktop environment is wmii running on Linux. I also
find Windows physically painful. The problem is that the reason this works for
me is that I'm able and willing to put up with an awful lot of bullshit and
have a reasonably good ability to debug things when they're not working
properly.

~~~
pdonis
I pretty much agree with your description of what it's like to run Linux.
However, I don't see how that makes Windows or OS X better than Linux.

With Windows, you have to put up with at least as much BS, if not more, and
whether or not you can debug things is irrelevant because the system is
opaque. At least in Linux there are plain text configuration files if the
worst comes to the worst.

With OS X, things work fine as long as you don't try to do anything with it
that Apple didn't explicitly design for. As soon as you try to color outside
those lines, it's at least as much BS as Linux, and while the configuration
files are technically text files, they're not plain text, they're XML (PList
files), which means that you end up having to use customized tools to hack on
them instead of a plain text editor. So debugging things is not as easy as on
Linux, although it's still a lot easier than on Windows.

