1) Are you thinking before you touch the keyboard?
If you have the mental model right for data structures, patterns, networking, caching, then you'll have fewer bugs. Get the mental model wrong, and one can treat a bug as a code smell, it probably indicates a fire that you've just not noticed yet.
2) As all bugs that have ever gone live have got past testing, Q&A and user acceptance... are you better at reacting to the unexpected (bugs) than the expected (testing)?
Bugs will happen, best to have great processes for when they occur.
I advocate insane measuring and monitoring which means thinking of instrumentation when you author code. This goes back to thinking, as a team and company one can fight the cargo cults with evidence. Monitoring and measuring dramatically reduces the time it takes to react to an incident, and guides which things should be tested in future.
Agree completely. At this point it's part of our process to write design notes as the first part of a pull request.
My co-founder has been adamant that not enough time gets spent on the high-level architectural pieces. And I've personally found, after finally listening to him, that the more time I spend on architecture the less time I have to spend implementing.
I can't stand developers who "feel" their way through projects. Take the time to make a design document, whether it be a list of bullet points or pseudo-code. Something is better than nothing.
With all due respect -- that is just how some of us work internally. We learn by experimentation, intuition and repetition.
I often find it extremely difficult to write a design document for a system, particularly a system owned by somebody else. I have written design documents in the past, and they rarely end up describing the eventual system, no matter how hard I work to maintain and update them.
In my experience, software design and engineering is an iterative process, like gradually groping in the dark to determine the shape of a room. I cannot simply turn on the lights and take a photograph of the room at the start of the project.
Having said that, I completely agree that in principle it is great to start new projects with a complete design document, at least a functional specification. Accurate technical specifications are a rare, elusive beast, though.
If you don't know what you're trying to build, you probably aren't going to manage to build it. But in practice, you never actually know for sure, because things always change.
You should know how you're going to build it (the architecture). But in practice, my ability to be omniscient is very limited. As I implement it, I find out that my design/architecture was wrong.
Maybe the key factor is this: When you find out that the architecture is wrong, do you fix it? Or do you just hack it to get the next bit to work?
> When you find out that the architecture is wrong, do you fix it? Or do you just hack it to get the next bit to work?
That's very project and organization dependent. Some projects are short lived prototypes (I'm working on one now) that are for internal use only, so it makes sense to try and get the damn thing finished without worrying too much about architecture.
Other projects are built to last, or have very high quality requirements, so you want to really get the architecture right, even if that means costly rewrites.
(Reading this a few days later in an open tab. :-) )
Imho the most important thing is to have a good design document for the data model. Partly because it often decides a lot of the structure of the code.
It is e.g. easier to rewrite code than realize that you lack some stuff you should have captured about customers years ago...
1) Are you thinking before you touch the keyboard?
If you have the mental model right for data structures, patterns, networking, caching, then you'll have fewer bugs. Get the mental model wrong, and one can treat a bug as a code smell, it probably indicates a fire that you've just not noticed yet.
2) As all bugs that have ever gone live have got past testing, Q&A and user acceptance... are you better at reacting to the unexpected (bugs) than the expected (testing)?
Bugs will happen, best to have great processes for when they occur.
I advocate insane measuring and monitoring which means thinking of instrumentation when you author code. This goes back to thinking, as a team and company one can fight the cargo cults with evidence. Monitoring and measuring dramatically reduces the time it takes to react to an incident, and guides which things should be tested in future.