Is it possible to predict how many defects will be encountered in acceptance test or production? What number of defects would be considered reasonable versus signs of low or high quality? These are questions I considered when my last project entered acceptance test. At the time I had no good answers. So over the past [...]
Posts Tagged ‘software development’
For any software development effort a core component of planning how to achieve high quality is the selection of the quality-enhancing activities and practices that will be performed to assess the software. This selection depends on a number of factors including the capabilities of the team, the characteristics, complexity and criticality of the software, the [...]
I had a manager a short while ago ask me who was responsible for quality within their organization, within the context of software development projects. Without having to think about it, I knew the answer. It was intuitively obvious, but it was an intuition fueled by reading hundreds if not thousands of pages about lean [...]
I believe there are two primary flaws in focusing on plans. The first flaw is the assumption that following the plan will achieve the goal. Sure, the plan is assembled with the intent of meeting the objectives, but what guarantee is there that this will actually happen? The second flaw is putting one’s primary attention [...]
- Add Comment
- No Comments
- Permalink
Most of the requirements I deal with are in the form of documented use cases and lists of business rules. These requirements are almost always written in a generalized form. For example a business rule might be written as “Produce a warning if the last transaction in the account is more than a year ago.” [...]
I have written numerous times about defect elimination practices such as code reviews, unit testing, and static code analysis tools. From the perspective of lean thinking, however, eliminating defects, no matter how soon after they are introduced, results in waste due to rework to fix the defects. The ideal as far as lean is concerned [...]
I have recently been wrestling with the problem of clarifying the concept of capability levels for software developers. What does it mean to call a developer junior versus intermediate? How can a developer at one level progress to the next? How do you evaluate the capability of a developer? These questions and more formed the [...]
- Add Comment
- No Comments
- Permalink
How do you go about designing and coding software? More specifically, what is your mental process for accomplishing this? Becoming more aware of the approach you use allows you to deliberately control and improve it. Mental thought processes are, however, very intangible and difficult to put into words. In the software development literature much has [...]
- Add Comment
- No Comments
- Permalink
If the goal of software development is to produce working software then developers need to know more than just how to code – they need to know how to prevent or eliminate functional and non-functional defects. Too many developers think their job is complete once a feature has been coded. Sometimes they think that it [...]
There is an interesting relationship between having predictable estimates for project management and using a thorough definition of done. Achieving the full definition of done for a feature or release (often called being done-done) is surprisingly difficult. You may have heard the anecdotal rule of thumb that it takes 80% of the time to achieve [...]
- Add Comment
- No Comments
- Permalink
I have written previously about the importance of having a definition of done that the team understands and adheres to. At the level of features (use cases, user stories, etc.) a comprehensive definition of done will often consist of a number of items, some involving non-developer roles such as tester, business analyst, and architect. Tracking [...]
- Add Comment
- No Comments
- Permalink
I am a big proponent of using to do comments – comments prefixed by a specific identifier such as “TODO” – in a code base to indicate outstanding tasks or issues with the code. I have encountered developers who are either unfamiliar with the practice or who do not follow it as deliberately as I [...]
My previous article discussed the importance of defining success as it relates to software projects and products. Now I want to look at some typical definitions of success and identify problems or short-comings with these definitions. From this analysis I aim to point the way towards a better definition of what success entails. Typical Definitions [...]
- Add Comment
- No Comments
- Permalink
I was recently doing some performance tuning and made the surprising discovery that doing less caching in Hibernate actually improved performance in a particular scenario. When I discovered the problem this seemed very counter-intuitive. In fact, my original design maximized the use of caching in order to improve performance, but the opposite happened in practice. [...]
Can you define what makes a successful software development project or product? Do you know the criteria by which your current assignment will be judged a success? Does everyone associated with the project or product share the same definition? Defining what it means to be successful may seem obvious or trivial, but I expect that [...]
- Add Comment
- No Comments
- Permalink
Over the years I have refined the approach I use to write code. Recently I codified a key aspect of this approach as a practice I call the Use Understood Methods Rule. The basic formulation of the rule is quite simple: when coding a method only invoke other methods whose behavior you clearly understand and [...]
I wrote previously about the process I went through in adopting test driven development (TDD). In this article I discuss my experience with TDD: the benefits, the limitations, and the techniques I use when doing TDD. Benefits This section covers the benefits, as I see them, of doing TDD. This does not include the benefits [...]
I have always been keen on using automated unit tests since I first heard about them almost a decade ago. I have known about test driven development (TDD) for almost as long but the practice of writing tests first before writing production code never really clicked for me when I first tried it years ago. [...]
I recently wrote about why you need a definition of done, and it only seems logical to follow this up by presenting what I use for a definition of done for developing software. I use two guiding principles as the basis for constructing my definition. Potentially releasable: Ideally the software can be released (or shipped) [...]
Would you trust your life to your code? It is a simple question that you might find extreme. But is it really? You might argue that the answer to this question depends on the criticality of the software you are producing. Software like the control software for the space shuttle or software to control medical [...]
