The "Y"

Software industry is peculiar in many senses
I've seen very good softwares and very bad ones. I've spent many hours looking at code: mine, other's; at work, at home; for money, for free, for fun. Unfortunately, good code does not mean good software. On the other hand, bad code hardly (although it might) produces good software. Also, softwares should be long maintained after they are created. This becomes very very hard when code isn't good.

I plan to gather my experiences and those of my friends and enemies and share code quality assurance techniques, tools and tricks with you.

I will make numbers, reproducible and falsifiable. I will use your opinions to evolve myself. No comment (unless very offensive) will be deleted. I will include documentation, sources and trusted references when available. But in the end I will give you my opinion, right or wrong I hope it will do you some good.

Go back to the basics

You wanna win? Always go back to the basics.
Dr. Richard Webber in Anatomy, Season 2, Episode 22

When in trouble companies try to adopt industry methodologies standards, managing techniques, coercive tactics. None usually work, at least not as good as expected. They always forget about the basics. A software is built of code. Code is the base.

I don't mean I don't agree with methodologies, managing techniques and specially coercive tactics. Just that I think they, alone, will not succeed. You need to strike at the root of the problem.

Many different things can be done to improve the code. Some, you might like, others you might hate, some others, might even require too much effort/cost to be feasible.

The quality of the code is a subjective concept. For me the most important feature is maintainability, which includes itself many features. The point is, a code takes a relatively short time to be written and released, then it takes a very long time being maintained.

Programming is craftsmanship, is an art.

This is an art but not everybody can appreciate it. Dr. Miguel Katrib (my greatest mentor), refering to Arts Appreciation

I made my first program 20 years ago. It was Basic on an MSX. It defined my life. Many years had to pass until I got to University and discovered most of the programming I think I knew, was wrong. Now every single day that passes I learn some of what I've done the day before was wrong. I learn much more from my failures than from my successes.

This will be a journey by misstakes and headaches not about success and enlightment.

Healthy software development cycle

for the developers

• Your code should compile with no errors at any time. Which means every change you made will not break local build. Every minute your code does not compile you are breaking the cycle.
• You should be able to run it often. Let's say every couple of minutes.
• Your changes should be integrable often, let's say 2 or 3 times a day you can check in changes without breaking the CI build and download latests changes without breaking local build. The longer you wait to integrate changes greater are the chances to break something when merging.
• You should be able to test everything let's say 2 or 3 times by release. If you only test once before a release and you find problems...then what? Delay the release?...customers and bosses will be furious! It will be better to delay one component/feature release than the whole bunch.

Quality checkpoints

There are many places to measure/improve the code quality. From the top, the user end till the bottom, the tiniest component. Each place has its features, challenges, pros and cons. I think a software cannot be quality assured only at the user end. Why? It's very hard to do: you cannot manually test everything; it's very slow, as software grows there more and more to test, there are new features that should be tested and also all existing ones should be constantly retested. We work automatizing computers, do we really think we can manually do everything they do? Do you? Well I don't. I think the human intervention should be the last barrier. Everything should be certified before reaching that point.

Embrace science not technology

I've seen a huge tendency to empower technology over science. Technology are the tools, the stick around for a relatively short time. Science stays forever. No body has ask me on an interview what an object is. Instead the wonder if I know Sql Server or MySql. I know relational DBs, sure there would be differences between me and the guy that really deeply knows the tool. What about when the tool get obsolete? it happens all the time. If you learn stone solid theory, you will learn the tools easily and get the most out of them.

Use documented and tested patterns

I love design patterns. There are tons of them these days. Trying to invent the solution to every single problem would be at best a waste of time. There are a lot of smart people which has analysed and published solutions for most of your problems. The greeks, 2 thousand years ago knew this. Do you think every architect invented the columns again and again? We, developers, constantly do. Use trusted sources: I love and write in code project, but it ain't, msdn and wikipedia either.

Standardize the code

Use code standards, naming standards, documentation standards. Setup tools to enforce them. Define them in assemblies, don't need to impose, get people's opinion. Evolve with time: C#2 standards might not be good enought for C#5.

Code analysis

Code analysis provides a way to know how bad your code is. As said before, it's not a measure that you could relate to software quality, but it helps. It is very interesting to see how it evolves in time. I plan to make some analysis with mostly open source programs from the internet and I will statistically try to relate bugs, costs and soo.

Testing

Nowadays we work with gigantic amounts of data. Huge problem domains. Components interdependencies reach from one point of the software till light years away. Testing is hard and exahusting. Event worst when maintaining. Every bug found by any stage should be tested for all the eternity.

Human testing

Humans are smart, brilliant and creative. But are slow(very) and expensive and lazy(even more). Machines do not get tired, ask Sarah Connor, are very fast, ask John. In every release cycle the whole software has to be manually tested, over and over. These tests should follow a checklist, a script. Testers should test everything that has been changed and everything the change feature connects to, which could be basically the whole software. We'll do the math some day, I promise.

Computers are much cheaper than people. If you think otherwise...this place is not for you.

Automatic testing.

There are many different ways to implement automatic tests. I will cover the ones I know and use. To start with them might seem like a waste of time. The good thing about automatic tests is once they are running they will keep running until the end of times. Regression tests will take longer and longer but we could just add more computing power.