Kirk Knoernschild

“Forward and sustainable progress can only be measured through a software system that works. There is no other way!”

Those are the words I uttered at our recent Catalyst conference in San Diego when debating the merits of agile development on stage with a colleague.

Requirements documentation, architecture and design models, and test plans may provide value, but they do not offer accurate insight into the current state of the project. While we may value these artifacts, we must value working software more. Without a system that works, there is no way to be certain that the development team is moving in the right direction. Continuing to develop and add new features to a software system that doesn’t compile, or whose tests fail, will only steer the development team further off course, away from their intended destination. Without question, it is counterproductive to add code to a system that doesn’t work. A software system with a multitude of compilation errors or failing tests only offers a false sense of security that the team is making progress.

The prime directive of software development states that a software system should always compile and its tests should always execute successfully.

From the moment the first line of code is written to the moment the team gathers for the “go/no go” meeting, and everywhere in between…the system must work. The software development team should strive to ensure the system can be built, tested, and executed at any point in time throughout the development lifecycle.

The prime directive assures the development team that they are building a system exhibiting the functionality their users demand. It ensures they are developing a system that performs, is secure, and is dependable. How so? The system is always functional, so it can be tested throughout the lifecycle. Customer demonstrations can be held that ensure the software meets the needs of the users. Important feedback garnered from these demonstrations allow the development team to adjust their course. Problems aren’t allowed to fester in the system for prolonged periods of time. As issues arise, they are dealt with by the development team. The result? No problem is ever older than the last successful build.

Of course, the prime directive has implications. If at any point in time the software is broken, it must be the priority of the development team to resolve the situation as quickly as possible. The software should never be left broken for an extended period of time. This can seem counterintuitive, especially for teams with severe deadline pressures. The prime directive demands discipline. And it is with this discipline that the development team is able to ensure sustainable and forward progress throughout the duration of a project.

There are many practices, agile and otherwise, that development teams adopt to improve quality, speed delivery, and increase project transparency. But each of these practices depends upon the fundamental notion that the software works. That is how it should be. That is how it must be!

4 Comments »

Category: Agile     Tags:

Share

Agile transitions are tough. Real tough! But there are some important practices a team can employ to increase agility without undergoing a massive agile transition effort. One of these practices is Continuous Integration (CI), and I’m hard pressed to imagine a software development team that wouldn’t benefit from a sound CI strategy. After all, if we cannot prove that a software system works, we must question if we’re truly making progress by adding code to a broken system. In fact, leveraging CI is one way to launch an initiative to increase the agility of a software development team.

On the Test Early blog, there’s a great little parody that offers a play on the proverbial rhyme, “For Want of a Nail”, which illustrates how even the smallest of actions (or lack thereof) can have significant consequences.

FOR WANT OF A BUILD

For want of a build, a test case was not executed
For want of test case, a defect was not detected
For want of a defect report, a bad release was promoted
For want of a good release, a strategic customer was lost
For want of a customer, a development team was reduced
For want of developers, a product stagnated
For want of a product, a company was lost
And all for the want of a build…

Source: http://www.testearly.com/2007/08/07/for-want-of-a-nail/

While the result as played out here is pretty extreme, the essence of CI is captured quite well. Emphasizing quality throughout the development effort, in lieu of attempting to verify quality at the end, will likely result in a much higher quality product. In other words, Build Quality In. CI helps us accomplish this feat through frequent builds and test execution that allows us to verify the system is always in a working state. Additionally, other important lifecycle activities are enabled that provide the important feedback necessary to ensure we never stray to far off the intended course.

Comments Off

Category: Agile Software Development Process     Tags:

Share

It’s exciting to be part of GBN, and I look forward to sharing opinions with each other. Make no mistake…this is a technology blog. But I hope to blog about technology topics in a way that helps folks understand the strengths and weaknesses of the technology, as well as helping them make the important decisions surrounding the technologies they’ll use going forward. I hope you’ll join me in exploration, and contribute your views.

Here’s a bit of what you can look forward to reading about in my little corner of the GBN world, along with my brief views on each. Over time, we’ll delve into each more deeply.

Software Development Processes and Practices

I’m an ardent believer that agile development methods and practices are *always* good, they do scale, and are a critical success factor for large teams. While that may sound overly zealous, I cannot think of any situation where slow, brittle, and resistance to change are beneficial attributes. Granted, my definition of agile may be slightly different from others, so this will be fun to explore.

Platforms, Development Frameworks, Software Architecture, and Modularity

The application platform that we’ve grown accustomed to over the past decade is undergoing transformation that stands to affect everyone from the developer to the folks in the data center. There is a lot of buzz surrounding the cloud, but there is also significant innovation elsewhere that promises to dramatically alter the tools we use to develop software. Dynamic languages that promise improved productivity and functional languages that promise improved performance are two examples. First class support for modularity (e.g., OSGi) that brings with it platform componentization and the opportunity to rightsize the platform is another. And each has a significant impact on software architecture of the future.

Rich Mobile Application Platforms

By now, I suspect you are familiar with these new breed of mobile devices garnering so much attention. Hardly a day goes by without an earth shattering announcement. The battle between Apple and Google is exciting to watch. Yet beneath these very public disputes lie an interesting set of dynamics. For instance, is Apple’s curated ecosystem really the devil? Or might the fragmentation of the Android platform be a bit more concerning? And each affects how you develop rich mobile applications for the respective platforms, albeit in different ways.

Presentation Technologies

In the mid-1990′s, rich client technology was the rage. Remember PowerBuilder, anyone? Of course, the web changed all that, offering a near ubiquitous platform for delivering the corporate brand to consumers. Unfortunately, web technologies presented new challenges. Rich internet application technologies (RIA) such as Ajax and Flash helped overcome some of the user experience problems, but others persisted. The lack of local storage and inability to access applications in the absence of an internet connection are two examples. While new technologies such as Silverlight and AIR promised to finally overcome these challenges, HTML 5 aims to do the same. And on the horizon looms a rather interesting battle that will redefine the web.

While the above topics are my primary interest, I cannot promise that I won’t occasionally stray and discuss other topics, as well. It should be fun.

Comments Off

Category: Mobile Platforms & Software Architecture Presentation Software Development Process     Tags:

Share