Category: quality
Software engineering is still a very human endeavor. Its a complex process that requires our ability to create non-standard solutions for non-standard problems. But with this ability to creatively solve problems comes a tendency to introduce defects, one of the seven wastes lean production and lean programming try to eliminate. Jack Milunsky describes several ways to reduce the amount of defects in his article. I want to look at another idea from lean manufacturing for reducing the number of defects called Poka Yoke in Japanese and have a look at how we can apply this idea to software engineering.
Bookmark/Search this post with:
I was doing a quick research for this article using Google trying to find arguments standing for the claim that "quality is expensive". I was trying to find some resources saying that care for quality in the early stages of the software projects doesn't make sense and doesn't pay - I find it very difficult and I cannot share with you any reasonable links (maybe except for this one which refers to another post saying that "Quality Sucks").
What does it mean? It means that software people know that quality is very important. Why then quality of software products sucks in more cases than it rocks?
In many big corporations following waterfall model there is a special team named QA (Quality Assurance). This team's responsibility is (not surprisingly) to assure appropriate level of quality in the software product. This is fine, this is perfectly OK, except that QA is considered as a separate activity. This is the "Verification" or "Testing" box in the waterfall model diagram.
The biggest problem with this attitude is that QA team gets the product after it has been implemented and this is the root cause of all evil. QA is considered as something separate - we first do the product and then we care about the quality. This way of thinking is wrong. You should care about quality from the day one, before you write a single line of code.
Software teams should "build quality in" their products and QA should not be considered as a separate activity. Quality Assurance should be constant process of improving the product - QA activities and people should be involved in the development of the product during the development, not after when the developers are moved to another projects or even teams.
In this post I will try to explain "Build Quality In" principle from "Implementing Lean Software Development - from Concept to Cash" book. I will present few practices that will help your team build software with quality built in.
Bookmark/Search this post with:
I was just reading an excellent book by Josh Bloch, namely "Effective Java, Second Edition" and I was on the optimization subject when it happened. It was funny coincidence but I think it was just a sign for me to write this post.
It doesn't relate to the Agility in any way but it relates to the quality of software so it should be definitely published here. And it all started very innocently - from publishing blog post with the solution to some annoying problem.
In this post I will tell you how easily you can fall into really dangerous and ugly development problems starting optimizing your software too early. I hope you will like the story.
Bookmark/Search this post with:
Many Finnish companies have a tradition of periodically selling the old stuff to its employees on the internal auctions. If you are lucky, you can get a decent computer, printer or fax for a couple of euros. Several years ago the company I was working for (CIM Wireless) has been bought by a bigger one. We were going to move to the new company premises and therefore had a particularly big auction where they were selling pretty much everything older, than a year. At that time I needed a new kettle and got one right from the company kitchen for as little as five or ten euros. I didn't put much thinking in, I just needed a new kettle - it didn't really matter which one.
When quality matters
It happened, however, that such a commodity as an electric kettle could be of so high quality that it makes you notice it. We didn't examine the device or measure its performance, but we couldn't miss such features as boiling water fast or ability to turn off automatically, when was empty. It might sound amazing, but we were actually surprised by the fact that it just worked very well. Plus it looked nice. We even recommended this model to a couple of friends - something you rarely do about kettles.
Bookmark/Search this post with:
Quality used to be perceived as one angle of the time-cost-quality project triangle. Unfortunately quality isn't as manageable as cost and time. If the funding is cut it is often possible to release a working product with the smaller set of features. It time is limited it is sometimes possible to hire the best specialists to implement all the features faster. It might sound like dropping some quality standards could be a way to releasing the product earlier.
Bookmark/Search this post with:
Some teams using Scrum and XP tend to have special Q&A iterations every several iterations and/or before the release. While it might be ok, during the transition to the agile processes, as a rule of thumb having Q&A sprints is a good indication of the problems with the definition of "done". The main point of iterative development is to have a "potentially shippable" product at the end of iteration. Planning for Q&A sprints essentially means that at the end of the iteration, team does not plan to have a potentially shippable product.
Bookmark/Search this post with:
We are not rich enough to buy cheap stuff.
- Russian proverb
Did you know, that the products with the lowest defect rates have the shortest schedules?
Bookmark/Search this post with:
I can recall several cases, when a seemingly clean'n'simple class appeared to be a huge and difficult to debug entity with loads of underlying asynchronous logic. The simple and small public interface hides the implementation details and according to the good Object-Oriented style all the underlying details are private. Or is it a good style to hide the implementation details into many private methods?
As it often happens, the problem comes from a good idea overused to the extent, where it inhibits another good idea. The encapsulation makes it easy to use your classes or systems externally, but it should not make you forget the internal structure of the class. As Michael Feathers tells
It often means that there's some other abstraction hidden away inside the class that might be useful to pull out.
Bookmark/Search this post with:
The program optimization is performed in order to reduce the execution time, memory usage, bandwidth or some other resource. Optimization essentially means sacrificing the clear, simple and understandable code architecture. As a result the level of complexity increases, debugging and restructuring becomes more time-consuming and more expensive.
It is simply a lot cheaper to get a clear working and testing code before the start of the optimization. As a side effect, a set of unit tests (if you practice them) will protect you from the potential regression coming from the optimization actions.
Bookmark/Search this post with:
Managers don't speak C++, refactoring and some of them don't trust the programmer's "feelings". To sell TDD to them, we have to speak the management language of costs, deadlines and delivery delays. Apply some management language and you'll be able to start the TDD.
Killer argument tips:
1) Extra testing saves at least some time of the final test round
2) Extra testing improves the code quality at least a bit
3) If extra testing is applied to the most important components and interactions, it takes not that scary amount of time
Therefore even in the worst case the time spent on the extra testing will be partially compensated with the better quality and smaller final testing efforts. And in the best case, both quality and delivery time will be improved significantly.
Bookmark/Search this post with:
RSS feed
Subscribe on Kindle