Archive for February, 2010
Bug tracking systems are bottlenecks, they perpetuate the continuous handovers between testers and developers and they require extensive documentation to be maintained.
The standard life cycle of a bug is usually as follows: A QA tester finds an error in the application, creates a new bug in their bug tracking system and sends it to the developer, which in turn, as soon as he fixes the bug, notifies back to the QA tester, which then, notifies the product owner which then, closes the bug.
In paper, the previous process sounds wonderful, but there are quite a few drawbacks.
- Communication problems. Sometimes the description of the bug is poor, or the developer misunderstands the problem.
- Regression testing. This process requires the handover of code back and forward between QA and development, this causes versioning problems and duplicated testing effort.
- Low robustness. The process doesn’t guarantee that the error will appear again in the future.
- Bureaucracy.Traditional bug tracking systems switches the team focus to bureaucracy from quality.
The solution for this problems is simple. When anyone finds a bug, he/she immediately writes an automated test that fails based on the bug just discovered. This mechanism have the following advantages.
- Gets rid of versioning problems, everyone works on the head.
- Guarantees that the bug is never gonna reappear undetected.
- Eliminates uncertainty on what the bug exactly is.
- Eliminates bureaucracy
- Consolidates the development activities in one place, the code.
The challenges to switch to this process, where a bug tracking system is not necessary are:
- Requires an automated build. This build have to be in place and running all the automated tests, so when a new automated test is entered because of a bug, the build will break and the team will have to take a decision whether they will fix the fix now, or whether they will ignore it for the time being (That way you will know that all the ignored tests are non-fixed bugs)
- Requires cooperation. Developers and testers must work together so they can create new tests as soon as they find new bugs. You are going to require testers with programming skills.
- Requires discipline. The team must understand that without exception, for every bug found, a test is created, and for every time the build is broken, the priority is to fix the build.
- Requires organization. Tests must be created with criteria and using a common naming convention.
Summarizing, in my opinion, the future of bug management is to get rid of all the traditional bug tracking systems and all the bureaucracy, I also think, as explained just above, that there are quite a few challenges, but if you have the skills and tools in your team to overcome them, I would seriously think about getting rid already of your old bug tracking system.
15 years ago, Microsoft released its first version of Internet Explorer. In 8 years, the mobile devices are going to take over television, computer, phone, gps, internet, console… Everything will be integrated in a single device. Internet connectivity will be universal and inexpensive. The 80% of the applications we will run will be web browser based.
Now, I may be very wrong with my previous prediction, but for those of you who think I may be right, how prepared do you think you are for this next challenge? I’m not saying that there is reason to be afraid now, or in a rush to learn new technologies, but if you think that you are going to be developing software in 10 years, it maybe worth asking yourself if you prefer to be leading what is probably going to be a revolution, or if you prefer to just be one of the developers that will have to go through a technological transition. In case you prefer to be leading, here you can find my personal suggestions to start getting ready.
1.- Get agile!
I already wrote an article where I expose my conviction that one of the current big changes in software development is the process, we are moving from waterfall to agile, in the future, in an on demand environemnt, where packaged applications are going to dissapear, being able to start deploying value to your customer ASAP is critical. Companies with a waterfall mindset will find it difficult to keep up with an environment which is going to demand the development team to be changing continuously.
From a developer point of view, this means that we need to start getting used to some engineering practices as TDD, continuous integration, pair programming, refactoring…
From an educational point of view, there are several great books, from which I would recommend the ones from Mike Cohn, Kent Beck and Martin Fowler, for those who prefer some more formal education, it is also available a certification program for the Scrum process, which is one of many different agile processes.
2.- Web browser development.
In the future, for an average user, the browser is going to be the only application he is going to use, how comfortable are you developing applications for it?
I think the following are the main areas where all developers should have a basic understanding.
3.- Mobile development.
We are actually not so far from an unique mobile device that integrates all our needs, currently new products as the iPhone, Android phones or windows phones are on their way to achieve it. Being able to develop applications for them can make a huge difference in you CV.
It is also important to consider that getting used to mobile development will also give you some experience on developing for an tactile and small interfaces.
4.- Security, Integration and Cloud computing
This on demand scenario I am talking about, is going to rely on a heavy server side load which the user is going to access through the Internet.
As developers we have the challenge to adapt our applications to this kind of scenario, the main challenges are;
Security. All the personal data from all the users is going to be stored in central locations which are transparent to the final user, being able to secure them is going to be fundamental, having a basic understanding of authentication, certificates, encryption, digital signatures… is going to play a major role.
Integration. The users will access a number of services and will expect them to interact with each other, to accomplish this, as developers we must be able to integrate our applications with third party applications with very small effort.
Cloud computing. Cloud computing means that the users are gonna access the applications as services where the backend infrastructure is going to be transparent for them, being able to have a basic understanding on cloud computing and its design challenges is going to be a key factor.
I love Legos. I got my first one when I was a kid. I remember the box had this awesome picture of a robot, so I opened it and started to play around with the pieces. It took me quite a while and I had to follow the instructions step by step, but finally I built it.
After that, I had a few more Lego and I realized that gradually I wouldn’t even need the instructions to assemble the pieces. The building mechanics became something natural: just pick one piece and connect it to the next one. It’s simple, powerful and most importantly consistent.
There are some other great building games and they are all based on the same principle: simplicity and consistency. Once that you master the mechanics of assembling the different pieces, the rest is up to your creativity!
But now, imagine that a new company offers a new building game where its pieces are mixed from other building games. Do you think it will be easy to build something with it? … Well, it will obviously be a disaster, it wouldn’t have any “Design integrity”, some pieces will be Lego, other pieces will be Meccano…you would be probably using glue to keep them together!!!
Design integrity, simplicity and consistency, play the same important role in software development.
Design integrity is about consistency, is about using always an ORM or always SQL to access the database, is also about using a the same dependency injection approach, or the same mechanism to communicate the different components of the application.
The key to create an integrated design is what Fred Brooks called in his master piece “The mythical man month”, the “Surgical Team”. The surgical Team is a small team, sometimes just one person, who supervises all the design and architectural decisions. In an ideal scenario, the surgical team has both formal and informal authority.
To success creating this surgical team, you need exceptional people, one of those 1 in 100 developers who really make a difference in the project, they also need to be excellent communicators, and they need to understand that they mainly have to coach and not impose. It is also very important that the rest of the team trust them and see them as leaders.
The main risk of failing to have an integrated design is technical debt. Technical debt is one of the biggest risks in software development: take too much debt and your project is gonna be in serious trouble.
My advice is: Get a surgical team ASAP or, if you already have one, make sure that they really are trusted by their colleagues and that they really understand the purpose of what they are doing. Having a good surgical team is one of the most valuable assets in a software development project.