> Writing good code is hard
So just strive to write code that _just_ accomplishes your objective.
> writing good tests is hard
So just write tests that are good enough to cover the code you've written.
> writing good docs is hard
So just write docs that are good enough to explain what's necessary to the audience for the doc.
I personally don't see the linked article as evangelical - but maybe that's because I'm brainwashed by the message it. But to me a 16 point list doesn't read at all like a silver bullet.
Re:Everyone can write bad code
by sodapopcan on Thursday February 08, 2018 @01:36PM
(#16334401)
I agree with all of this, but none of the points in this post are evangelical, they are just things that should be always considered. You can then evangelize about how to achieve each point. You can follow every one of these (or rather, do the opposite of all of these) and still write awful code.
Writing good code is hard,
writing good tests is hard,
writing good docs is hard,
and even harder is writing code to do the right thing.
If someone has lots of exploratory code, trying out different approaches to a problem, maybe producing some performance comparisons, maybe exploring that weird API the other part of the company is offering, these are all valid reasons to not follow a prescriptive methodology.
Yes, having short iterations with working software as a deliverable is great.
Having close contact with your user base for fast feedback is great.
Having continuous integration so that at almost any point we can see genuinely where we are is great.
But honestly, after those three, which I think compare to "use memory managed languages" in the list of genuinely useful software engineering innovations (and let's face it, none of them are software but process, and they are all arguably the same thing - fast feedback loops) I struggle with the religious zeal for pair programming or other "must haves".
it's not they aren't sensible practises, but with a gun to your head, you need to carefully choose what to throw away.
Trying to simplify my argument:
There are no silver bullets left in the software pistol. we can make our code as sweet as we like but the value will come from building the right thing, not building the wrong thing in the right way.