Posts made in 2010

« Older Posts   

Filter by Failure Mode Matrix: A Method for Planning Quality

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 […]

Who is Responsible for Quality?

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 […]

Mistaking Plans for Goals

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 […]

Ten Audit Warning Signs

I describe in my prior article how formal audits suffer from a number of drawbacks, and hopefully I have alerted you to the potential harm they can do. But some audits are necessary or can be helpful. So how do you detect when audits are causing you harm? Here are ten specific warning signs you […]

Drawbacks of Formal Audits

In heavily-regulated or bureaucratic environments formal audits are a common occurrence. Such audits typically consist of an auditor external to the team or organization who analyzes historical evidence of the work done to find non-conformities with respect to the documented process being audited. To those with a bureaucratic mindset process and audits are the answer […]

Example-Based Requirements

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.” […]

The Business Case for Dual Monitors

I debated posting this as there seems to be a broad consensus amongst I.T. bloggers that dual monitors should be a given for software developers. Leading the pack is Jeff Atwood, who posted about three monitors back in 2004! The message, however, has not necessarily reached the management or facilities / infrastructure people at many […]

Defect Prevention Practices

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 […]

Contribution as a Function of Difficulty

In my prior article on capability for software developers I identified four measures for assessing a developer’s capability. Three of these measures are closely related: the ability to work independent, the amount of assistance provided to team members, and the level of difficulty of tasks that can be handled independently. In this article I examine […]

Capability for Software Developers

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 […]

Remarkable Books Series

I am an avid book reader, always looking for inspiration, ideas, and insights. Over the last year I have read a number of inspiring books, each one containing at least one key takeaway that sticks with me. I think that sharing these insights here on my blog would be useful, but the idea of writing […]

Exploring Mental Processes behind Developing Software

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 […]

Why Coding is not Enough

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 […]

Predictability and Planning for Done

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 […]

Minimum and Optimal Thresholds of Competence

People naturally have varying levels of ability in the different aspects of their work (and life). These varying abilities are often divided into two categories: strengths and weaknesses. In the reading I have done in the literature on personal improvement, employee performance management, and entrepreneurship I have come across widely differing advice on how to […]

Spring Component Scanning Presentation at EJUG

I will be presenting on “Spring Component Scanning” at the Edmonton Java Users Group (EJUG) from 12 noon to 1pm on Tuesday, May 18 in the Western boardroom in the basement of the Canadian Western Bank building, located at 10303 Jasper ave. I’ll be talking about my experiences and lessons learned using the component scanning […]

Using Feature Done Checklists

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 […]

Using To Do Comments in Code

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 […]

Problems with Typical Definitions of Project Success

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 […]

Avoiding Caching To Improve Hibernate Performance

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. […]

« Older Posts