What is software quality
There is and always have been a huge gap between the end product and the code. That gap has been introduced some ages ago with tapes and cards. They didn't make any sense whatsoever to the end user as much as the code today makes no sense whatsoever to the user of your next brilliant application. Let's face it: programming is an art not everyone can do and even less people can understand (even if they are in fact doing it). So what makes up for a quality product?
There are 2 sides of the story: one is the "make it to the market ASAP" side which tends to solve the problem of competing with others. Depending on the size of the project it might seem like it is a good idea to rush developers into doing the least that'll actually work or to push in some features that'll make the customers so much happier.
The other side of it is that software is created by human beings and that in turn reveals the weakest link in the process of creation. Even though we can be extremely creative in our brilliant ideas we tend to make mistakes, tons of them. The faster you write code the less careful you are and the more bugs sneak in into the final creation...
Sure there are people that get it right the first time, always, but there's so few of them you could put them into the "exception" group for a rule that programming is a very error-prone activity.
So quality in the broader sense is something that is good for both the end user of our software as well as the agility to fix any bugs or introduce new features into the project.
I can fix any bug in the projects I wrote - and do it FAST!
That's a common misunderstanding that one can find bugs within software product they wrote. It is so because we, humans, don't stay the same for the duration of our lives. We tend to learn new things even if we don't admit it to ourselves. Let me tell you that looking at the code that I created 10 years ago scares the hell out of me! And I'm not the only one...
So even though we'd like to think that if we'd be the only ones creating the software we will at some point face the danger that our old idea was plain wrong. Due to the changes that happened to our lives we tend to think differently and curse that brain-dead monkey that wrote this stuff some years ago.
Uncle Bob says: Why did you write it?!
One should always try to be at ones best when writing code. Period. There's no excuse for writing unsustainable code - be it for private use or for the company you work in. There's no excuse to write code that will make you ask WTF every 5 moments. That'll make your life and the life of your fellow developers a living hell. And the worst part of it that it is not only you, the programmer, that will suffer from it - it's everyone in the chain starting with the guy that wrote it and ending with the programmer's worst enemy - the end user... How come? Well first of all you will curse the day you entered the project, then your architect will throw thunders at you for writing that piece of crap, then your manager will tell you that you need to go faster and cut corners and at the end of all this there is the customer that will probably go ahead and buy another solution that will not break as often as the piece of crap you and I created.
My old boss when asked about what is software quality explained it more/less like this:
The quality itself is not a goal for itself. But at the same time it is vital in order to sustain the company and the products it delivers
What it says is there's no one or the other. The world is not gray in this regard. If you make a loan in the code you'll have to pay it back in order to go further...
Summary
The summary of the whole series is quite simple: do TDD, do continuous integration, do pair programming, do code reviews, do make the querulous customer happy! They deserve it. You deserve it. You deserve to do the right thing. And if you can't do that then quit now and never look at software development again.
No comments:
Post a Comment