Recently we were gaining feedback from a client when they were at their most honest (after a few beers) and my colleague posed the question “Is it our process or our people that add more value?”. We debated it on our current project and past experiences and my initial gut reaction was that it is definitely both. I’ve been on projects with good people using big up front design, heavyweight documentation for documentation’s sake, and a lack of automated testing and I personally felt the lack of efficiency and tremendous amount of waste that the team produced. They were some of the better software developers I’ve worked with though, so the process is definitely important.

Conversely I’ve worked with or managed teams that leveraged agile methodologies and lean processes and tools and I’ve seen first hand the friction that one or two people can produce that bring these otherwise highly capable teams to a halt. Whether the issue was ego, lack of experience, unwillingness to learn, or inability to improve, if these people were surrounded by other talented individuals and a viable process, how could they bring an entire team down around them? Obviously, people are just as important as the process.

In each of the instances where individuals created havoc, the friction was caused by a person with a different set of values than the rest of the team. One of the things that really excites me about my current team is that there is no question what motivates us to sling bits on a daily basis. We are striving to delight our customer with the software that we produce. End of story. There are no misconceptions among the current team or potential team members about what we do, so there are no issues with individuals having values that are contrary to the overall team goals. We are lucky in that we also have a proven, lightweight process that enables them to be successful. So back to the original question, is it the people or the process?

At the time we discussed this, the agile manifesto value of “ Individuals and interactions over processes and tools” did not even occur to me. The thought leaders those many years ago already answered this question in the same form as my client. Both can help, but the key is people. In my own personal experience however, I saw poor results with great people, so what gives? Further reflection revealed that the missing ingredient with that fore mentioned team was empowerment. Bringing great people onto a software development team can yield equally good and bad results, the key is to make sure that these team members are empowered to do what’s right by the end goal. Empowered teams will have the wherewithal and courage to stand up and change a process that is not working. They will also become self policing and weed out other team members that are later found to have a different value system than themselves. In short, hire great people, empower them to do what’s right by your business, and then stand back and let the process evolve around them.

Photo courtesy of marianovsky on flickr.

As developers we need to be acutely aware of our end user’s needs. We collaborate with them on system and interface design, we demonstrate progress at frequent and consistent intervals, and we proactively gather their feedback and incorporate it into the final solution. The end result of our efforts, working software, is continually on display to these users and like a Pavlovian dog, we desperately seek their approval of it. This is a very good thing; the most successful products typically spend significant dollars on user research to determine if the final product will delight their customers. When developing software though, the end users are only half of the target customer that developers should be concerned with.

The people who tend to look at our source code most often are not the end users; they rarely if ever see the kung fu we wield within our editor. The audience we need to be concerned with is the group of poor schmucks who have to triage our defects at 3am when the billing system goes down. It is the new guy who was indoctrinated into the group by being tasked to replace all of our table-based layouts with a CSS based approach. Your audience as a developer is the person sitting beside you who one day will have to change your code even though they have no context to know what you were initially thinking when building it. This is the audience we as developers need to cater to and we are horribly averse at gathering feedback from this key group.

I’m obviously speaking generally here, but why are we as developers so averse to showing off our source code? Embarrassment, bruised egos, laziness, and a perceived lack of value are viable and accurate reasons why developers resist gathering the same amount of feedback on source as they do on software. None of these reasons however, can outweigh the dramatic drop in efficiency that comes with producing a complex code base that is difficult to read and maintain. Roger Pressman notes in the book Software Engineering: A Practitioner’s Approach that 80% of software costs occur in the maintenance phase. If the vast majority of our effort will not be in creating the initial solution, but maintaining it, how can we be successful without some level of feedback from our peers on the quality of our source code?

The short of it is, you cannot be successful in this model. Organizations have spent countless iterations creating new solutions, watching them rapidly degrade into systems that cannot be enhanced, and then re-creating a mirror replacement system with new frameworks and languages that are just as apt to be termed legacy as their predecessor. Legacy systems can be built in any language or tool (some more than others, no doubt), it is the responsibility of developers to solicit feedback from their peers to ensure the end product is readily evolved.

If developers can put their egos aside, a number of tools and techniques are at their disposal. Pair programming provides continuous feedback from a member of the target audience. Initially popularized as a quality measure, pairing also gives developers another perspective into the relative complexity and readability of the solution. Code reviews are sometimes deemed unnecessary when pairing is in place, but these two are not exclusive practices. When pairing, developers will communicate and collaborate to progress from a blank slate to a final solution. In other words, both members share a good portion of the context within which they are working. The poor schmuck at 3am talked about earlier does not typically have this context. Code reviews can mimic this blind immersion into a solution and often provide further valuable insight into how quickly others will understand the source.

While legacy source code can be produced in any language or framework, there is no doubt that many languages value essence over ceremony more than others. Ruby has gained significant popularity for this reason and the number of DSLs building on top of this language are expanding it’s presence into testing, building, and integrating within other languages like Java and C#. Even if you cannot leverage Ruby or a higher essence language like it, you can probably still find fluent interfaces, leverage better variable naming, and pick up on many other tools to ensure that the poor souls following in your footsteps have at least a fighting chance. Regardless of the tools used, be sure to get your code in front of other developers and get feedback. Without consistent, unabashed input on how well your source code is understood by your developer audience, you’ll never be able to say that your solution is truly meeting the needs of it’s users.

It seems like every week there is a new programming platform being announced. By platform, I mean a device or software environment that has a Software Development Kit (SDK) that allows third-party developers (you and me) to build our own applications on top of the existing software stack and device. The examples you will be most familiar with are the Apple iPhone, Google Android, Facebook and Google Wave (although we will discuss others here).

I think we are looking at these platforms all wrong. The industry’s focus is only on two places: consumers and advertising. On the iPhone, for example, the overwhelming majority of applications are games. The few applications that are not games are purely consumer focused, not business oriented. And when I say “business oriented,” we have to think far beyond advertising. Yes, these platforms supply another potential channel for advertising to consumers. But that is a mere sliver of what’s possible. Why limit our business application thinking to advertising, which, at best, is tolerated by customers, when we can use the features of the platforms, and the knowledge inside our businesses, to take people’s lives to a new level?

In this blog post, I will outline the platforms I think are the most exciting, starting with the platform that almost singlehanded redefined the field – the iPhone. Then I will share a few of my initial ideas on how businesses might take advantage of the power of these platforms.

Phones as Platforms – iPhone, Android, WebOS, Blackberry

The Apple iPhone offers so much as an application development platform. The full screen on the front of the phone put it head and shoulders above its predecessors like the Palm Treo. The real magic for the iPhone came when Apple announced the SDK and the App Store, turning the iPhone from another phone into a bona fide app dev platform. The iPhone might have less memory and more restrictions than a desktop computer, but it also have many more inputs and interfaces, providing so much more information to programs that run on its platform:

• Camera – let’s you take a photo and send it to someone within your app, plus you can add different types of recognition (optical character recognition, universal product code recognition, facial recognition), then, once something has been recognized, the iPhone can connect to the Web and search based on what it “saw”
• Motion Detection – certainly the iPhone can tell if something is moving in its range of vision (through the camera), but it can also tell if the device itself is moving, through some sort of gyroscope, I guess.
• Maps – Being able to see a map (that is up-to-date!!) while you are moving around is a big help, details can include traffic issues, downed power lines, etc.
• Global Positioning System (GPS) – Combining map technology with knowing where you are on the map has all kinds of possibilities
• Augmented Reality - This isn’t a technology at all, but just a new way of combining the use of the camera, motion detection, GPS and connection to search. For instance, one augmented reality program allows you to look through your camera at an apartment building and see which ones are for rent. You can see the actual physical apartment on your camera’s screen, and then there are rental details overlaid based on your GPS location and the results from Web searches. It is an amazing mind-shift (one I’ll talk about more in the Ideas section).
• Connections to Your Friends and Co-workers – The iPhone has a list of your friends and their contact information and can easily send a text message (or e-mail or tweet or…) to people from within your application telling them what just happened to you and your phone

I’m focusing on the iPhone, but of course, even the iPhone has competitor platforms like Android and Palm’s WebOS. And the Blackberry platform has long been a staple for business applications, but I don’t think it has been exploited to the extent it could be. Blackberry is an obvious platform for business applications.

Readers as Platforms – Amazon Kindle, Apple iPad

Amazon recently announced the Kindle SDK, allowing third-party developers to create applications that will run on this fantastic electronic book reading device. And, the much-talked-about Apple iPad was just announced, which will run iPhone applications, but since it has a much larger screen (almost 10 inches), many developers will likely redevelop their applications especially for the iPad platform.

The Kindle has the following features that we can exploit:

• A screen that mimics a written page, allowing people to read for hours without eye strain
• Ability to show finely detailed diagrams and images (although only in black and white)
• It knows to re-orient the screen when you tip it to one side
• It connects to Amazon’s book store (and potentially to other sites)
• A hardware keyboard
• A very limited browser
• Automatic subscriptions, like the ability to deliver the New York Times to your device every morning with no effort on your part
• Ability to make notes, highlight and bookmark books
• Sync books (and pages read) back to Amazon’s book store
• Backup storage of all electronic books purchased at Amazon in case of accidental deletion or device problems or loss
• Knowledge of which books the user has read, wants to read (wish list) and is currently reading (even which page they’re on)

Although the Apple iPad does not have an integrated hardware keyboard (it is a separate item) and has a backlit screen (causing similar eye strain to a regular laptop screen), the iPad has several advantages over the Kindle, from a programming platform perspective:

• Color screen
• E-mail access (and hopefully integration for apps)
• Video viewing
• A fully-featured browser
• Some portability for apps between iPhone and iPad (although most programs should probably be written to take advantage of each platform’s strengths)

This category of electronic book readers (although the iPad is much more than that) is a potential set of platforms for business applications as well. More thoughts about that in the Ideas section.

Application as Platform – Google Wave, Facebook, Twitter

I think this is an area where we haven’t begun to tap the business possibilities. Let’s examine what these platforms provide us in their SDKs:

Google Wave:

• Combining the functions of e-mail, blogging, microblogging, photo sharing, video sharing, forums and chat in one application
• Synchronous interaction (real-time like instant messaging) combined with asychronous interaction (non-real-time like e-mail)
• The formation of temporary or permanent discussion groups

Facebook:

• Knowledge of who your friends are
• Keeping up-to-date on what your friends are doing day-to-day
• Being able to accomplish things with your friends and coordinate activities
• Knowledge of yours and your friends likes, dislikes, interests, affiliations
• Application can communicate to your friends (within limits)

Twitter:

• Direct messages (avoiding spam)
• Knowledge of what your friends are doing by reading their tweets
• Real-time news feed of sorts (trending topics)

Of course, these are just a few of the social applications that have APIs and can (sort of) be considered a platform. Twitter has tons of third-party applications using its APIs. Facebook has a lot of applications, however 99.9% of them are games or quizzes. Nobody is thinking about how to use Facebook in ways other than strictly entertainment. Why not?? Again, let’s not talk about the advertising potential. Maybe advertising can work on Facebook, maybe not. But there is so much more to think about beyond advertising in a business sense.

Operating System as a Platform – Jolicloud

An operating system as a platform?? Now I’m really walking on the edge, aren’t I? But Jolicloud is a bit different than the operating systems you might be thinking of. Jolicloud is a new “cloud operating system.” It is particularly targeted at netbooks, although I was able to get it up and running flawlessly on a regular HP laptop. But, as you can see in the screenshot above, Jolicloud treats locally installed applications (like OpenOffice or Skype) exactly the same as Web-based applications (like YouTube or Twitter). This seems very powerful to me. I like the thought of seamless interaction of local software (or not) with Web services (or not). Who cares where the application resides? Just give me the functionality. What I’ve noticed about Jolicloud is that it is oriented towards extreme ease-of-use. Updates to any application (local or Web-based) operate the same way, and a single click updates everything at once.

Jolicloud is nowhere near the other platforms in maturity. At this time, I can’t even find an SDK for it. Plus, the operating system is maddening slow. But I can see the potential here. What can we create for netbook-specific platforms that give us an advantage? How can we go beyond locally-installed OR Web-based to a model that has both side-by-side?

Television as a Platform – Boxee and Roku

Several months ago, Boxee announced their SDK, as well as the Boxee Box. Boxee is an open source software application that acts as a channel changer for all the video that is on the Web. Instead of having to go to Hulu, then to CBS, then to YouTube, etc. you can have it all in one place and mark programs as your favorites, etc. Until now, that meant either using Boxee on your computer or connecting the computer to your television to watch big-screen. But next month, Boxee is bringing out the Boxee Box, which will act as a controller for your television by connecting to the Internet wirelessly and queuing videos for you to watch on your schedule, similar to Roku.

Roku has had a partnership with Netflix for several years to allow customers to download Netflix movies straight to the TV, using a small black box (running Linux) that connects to your wireless home network and then wired to your television. We’ve had this Roku box for several years and it works flawlessly. Now, Roku is adding multiple new channels, including a Facebook photos channel (your photos), TWiT (technology news), Major League Baseball, and many others.

But that’s not the real news. Boxee and Roku now have SDKs and are working towards becoming full-fledged development environments. Literally, as I was writing this post (it has taken me several friggin’ weeks), Roku announced their SDK. What can businesses do with this information? What apps (don’t think ads) can you develop that will help your business and your customers?

My Ideas

If it isn’t games, and it isn’t ads, what can we do with these platforms? Here are a few of my ideas, which will hopefully get your mind leaping far ahead of me and into this new realm. The ideas I’ve written below are lame-o compared to the ones you’re going to think of.

1. Airplane in your yard – For an airline, develop an augmented reality app for Android/iPhone/WebOS/Blackberry that allows you to experience the size of the jet you are making reservations for? Let’s say you are on your phone, making a plane reservation, using the JetBlue app. You are a tall person and you’d like to know exactly how big this plane is. Will you have to duck to walk down the aisle? Will your bag fit in the overhead compartment? The JetBlue app informs you that the plane is available for your walkthrough out on your front lawn (or any nearby open space). You walk outside your house, bring your carryon bag, and look through the camera of your phone. There is the plane, alright, life size on your lawn (using augmented reality)! You walk into the open passenger door and notice whether you need to duck to walk down the aisle. Then you stop and take your real-life carryon bag and try to fit it into the (virtual) overhead luggage compartment. Compliments of JetBlue, you now know whether you are going to be comfortable on this particular aircraft or not.
2. Grocery store navigation – For a grocery store, develop an grocery list application. The person enters the items they want to buy while they are still at home, let’s say on an Android phone. Then they come to the grocery store, and the application (knowing which store this is using GPS), re-arranges the list so that the person’s route through the store is the shortest. (Yes, I know the prototypical data warehousing story on how to force the guy buying beer and diapers to walk through as much of the store as possible. Screw the customer to make more profit. No thanks.) Then it lights up the aisle and shelf where the next item is (looking through the camera again – augmented reality). Imagine fireworks, spotlights or something to highlight where the item is.
3. Herbal Remedy Info – For a natural foods store, develop a herbal remedy information application. The customer loads the app on their phone, then looks through the camera at the shelves, the phone camera uses product label recognition (already available as Google Goggles) and overlays the types of conditions the herbs are meant to help with. If you’ve ever used herbal remedies, you may notice that the products cannot say what they can be used for. This is because the drug companies have lobbied the Federal Drug Administration (FDA) to keep the herbal product companies from advertising any type of benefit (helps you sleep, heals infection, etc.) because the herbs do not go through a certification process (costs millions of dollars and isn’t worth it for an item that cannot be patented). But with this app, any customer can see at a glance (through the camera phone) what usage each type of product has. Valerian root can help you sleep. SAMe helps with mild depression. And, again, the customer could type in a product or product category (or symptom) and the store aisle (and shelf) where the product is could light up on the camera screen.
4. Every magazine on a reader device – But enough about phones, what about electronic book readers? First of all, I cannot figure out why magazine companies are not rushing to produce Kindle and iPad versions of their magazines. Every magazine in production should have an electronic version, and the Kindle and iPad are good places to start. The number of magazines available on the Kindle can be counted on your fingers. Terrible opportunity to miss.
5. Auto-delivery of new car model brochures to reader devices – When I was a kid, I used to write to car dealerships and ask them to send me the glossy sales brochures of the new car models. They almost always did. I loved looking at the beautiful images and cutting them out for collages and stuff. If I ran a car company, I would have a subscription service where people could request automatic downloads of the new car models as they come out. The brochures could come straight to my iPad (color is nicer) as soon as the new model year is announced. Call it advertising if you want, but to me, there is a difference between advertising and helping people buy from you.
6. Create a company channel on a TV device – It’s one thing to have videos available on your company Website, but quite another to create your own TV channel. Roku and Boxee allow your business to create a video channel for information about your products or services. Help customers to learn how to buy from you. Post detailed how-to instruction videos, previews of new services coming up, interviews with existing customers. Provide wisdom, don’t advertise. You could also use Boxee’s platform for an internal, employee-oriented channel. Provide company news, allow employees to suggest videos to each other and comment on the videos, all while sitting comfortably in their living room chairs. Boxee’s social networking features are far above what Roku has so far.
7. Let me live inside your movie – This occurred to me after seeing Avatar. Turn my neighborhood into the Avatar “blue world.” Turn my neighbor’s house into a giant tree. Turn my street into a footpath with giant dogs and running across snarling at me. Again, use an Android-type phone, camera, augmented reality. Imagine Lord of the Rings, Princess Bride (rodents of unusual size! LOL), Star Wars, etc. I would pay to get this app. Is it a game? Is it advertising? To me, it’s beyond both.

That’s probably enough to get you going. If you have ideas that you want to share, please add comments below. If you don’t want to share them, then build them!! We need a hard left turn on the current wave of games, ads and trash that is happening on these platforms today.

My inspiration for this post came mainly from two sources. First, Nationwide Insurance created an iPhone app to help people in the car buying process. And second, an incredibly innovative game called SpecTrek gave me ideas about what is possible for augmented reality.

I lost a bid today. Microsoft swooped us – promising to pay for the development and use some new software for the cloud.

Losing is not fun – but it happens some times.

As I walk away from this opportunity, I have to make one last final statement – “How you approach a project is more important than the back-end technology”.

Agile allows for a very clear focus on the Value Stories, the User Personas, The User Interactions, and getting to market as quickly as possible. I think my client understands this, but I’m not so sure they understand the dangers of embracing a new technology while they continue to cling to waterfall methodology.

I wish them well, but I write this as a warning to others who may be tempted to make the same mistake.

Choose your vendor/technology partner based upon HOW they will do your project first – then consider the back-end technology stack. I can predict a higher degree of success when this advise is followed.

I read an article about a year ago in ACM Magazine that I’d like to share with you. It explains how the General Accounting Office (GAO) of the U.S. federal government has asked government IT departments to go Agile.

First of all, who is more conservative than the federal government? And, within the government, who is more conservative than the accountants? When these guys are promoting something, it seems pretty obvious that there must be an economic payback, and, of course, there is.

This article lays out that there are four fundamental assumptions that have driven IT to date:

1. Dependable large IT systems can only be created using a rigorous engineering design process.
2. The key objective of constructing the application is to meet the knowable and collectable requirements.
3. Individuals of sufficient talent and experience can fully grasp the system.
4. The implementation can be completed before its environment changes.

But, the article states, these assumptions have failed us. A rigorous engineering design process takes too long, which causes our development cycles to be longer than the time it takes the environment to change radically. And this means that the knowable, collectable requirements at the beginning of the project do not represent the application that is needed at the end of the lifecycle. The constant change and uncertainty means that individuals cannot know and grasp the entire application at any point in time, because it will change under their feet as they take the time to understand it.

The article authors (including Peter Denning, long-time past President of the ACM), argue that government (and industry, of course) must have application development lifecycles that adapt to their environments.

I found this fascinating when I read it a year ago, and continue to find it so. The article authors do not accept that pre-planned/waterfall lifecycles are better in some cases, they argue that every application, even the largest, should be constructed in an Agile way. While you may not agree with their assessment, it is interesting to see how far the Agile bug has gone once it is being espoused by conservative institutions like ACM Magazine and the GAO.

Photo credit cliff1066 on Flickr

I am widely known as the prince of oversimplifications, but here goes anyway…

I strongly believe there are two major reasons why we should do projects iteratively and incrementally, i.e. in an Agile fashion.

The first reason is that “businesspeople don’t know what they want until they see it.” It is all well and good to show a businessperson a stack of requirements and ask them to sign off on it. But does that allow them to visualize the application? No. They are signing off blindly. Businesspeople (or any people) cannot truly understand a software application until they have seen it working on the screen and have played around with it a bit.

Can you imagine getting a person to understand Twitter without them using it? Reading the use cases for Twitter? It would sound ridiculous! And yet, it’s a good application.

Here is where I often hear people talk about user interface prototypes. If you show a user interface prototype to a businessperson, even though it’s a throwaway and there’s no guts to it, that should work, right? But it seldom does. Prototypes are NOT the real thing. And users get confused. “Are you already done?” they ask. “I’ll take it now,” they say. But it’s just a prototype, it’s not real. You can’t have it now.

If we slice our application development the right way, we don’t have to do user interface prototypes. We can show real, working, tested functionality every iteration. The businesspeople can look at it, play with it, give us feedback, tell us how to improve it. And if the business likes what they see, they can have it now. It’s the real thing.

The second reason we have to create software iteratively and incrementally is that “developers don’t know how to do it until they’ve done it.” I say developers, but we can lump all roles into this one.

My friend Bruce used to tell a story about when he worked at AT&T. This was back when they were truly the phone company monopoly and they had piles of money. He was on a project with them that went pretty well, and after about 10 months they finished the software. When they got to the end, the users and the software team got together and said “You know what? We really could have done this a lot better if we knew then what we know now.” So they did!! They got another big pile of money and started from scratch! They redid the requirements, coded everything again, retested, and gave it to the users. “It was fantastic!” my friend said. Everybody knew the problem to be solved. Everybody understood how to work together.

How nice if all our projects were like the “second time around” project. But they’re not. We don’t have the luxury that the erstwhile monopoly had in those days.

But what we can do is we can iterate. We can shrink our development lifecycle into a very short time, let’s say one week, and we can run through it again and again, learning every time. That way, we are getting the benefits of learning how to work together, how to use the tools, how to reduce the risks, but we don’t have to pay for the project twice.

For me, these are the reasons we build software iteratively and incrementally.

What do you think??

Photo credit SashaW on Flickr

Click here to see the photos from my presentation “The Basics of Agile” at Progressive Medical in Westerville, Ohio last Thursday.

(This is an excerpt from my upcoming book “Agile in the Bloodstream: Creating Change-Ready Teams Using the Power of Systems Thinking,” to be published August 2010.

Success is a lousy teacher. (Bill Gates)

The only way to learn is to make mistakes. What happens in your culture when someone makes a mistake? Is blame assigned? Is there a glare of attention on the person who made it? Is there any type of punishment meted out?

You can’t learn anything from doing something right. If you did it right, you merely confirmed that what you already knew or believed was correct. Nothing learned. But if you make a mistake, you can identify it and correct it.

There are two types of mistakes: commission and omission. An error of commission is doing something that should not have been done. An error of omission is not doing something that should have been done. You may think we’re talking only about errors of commission here, but actually errors of omission are much more serious.

Errors of omission signify a lack of innovation in your team. Maybe someone thought of a better way but was afraid to say anything. Or maybe nobody even thought about it.

What happens in organizations is that people get punished for committing sins of commission but they do not get punished for sins of omission. This shapes the mind of a person into saying “No, we better not try that,” attempting to avoid the nasty results of commission errors while ignoring the problems of omission errors, which don’t seem to cause as much havoc.

This helps build a team of people who try to create the appearance of doing a lot without actually doing anything. We all know the person who received one promotion after another even though it was widely known that they had never actually accomplished anything. That person is a symptom of a culture where mistakes are punished, not tolerated.

What you want to create, as a manager, is a Learning Organization. One way to do that is to tolerate mistakes by your people and not to punish them for making them. It is helpful to have “the speech” available, repeated by everyone from Thomas Watson of IBM to Larry Page of Google, which goes something like this:

“I don’t mind you making that (insert monetary figure here) mistake. I’m glad it happened. No, I’m certainly not going to fire you! I consider this money a well-spent investment in our organization’s education.”

For many years, people pointed to this oft-repeated but seldom practiced maxim as “the right thing to do.” But it’s more than that. If you do not practice this attitude towards people’s mistakes, you will create a Learning Suppression Machine which will cause your team to be unable to adapt to the changes it encounters and therefore a brittle mechanism instead of a thriving living team. The extent to which your team can overcome unforeseen obstacles (and what obstacles are foreseen??) is directly correlated to the way you handle mistakes in your team.

By the time you reach my age, your life patterns are fairly well established.

There are things I do as a matter of practice – part of my daily routine. I get up early, I eat a bowl of Raisin Bran Crunch, I read, I stretch, three days a week I go to the gym to work out. You get my point.

Our habits as “Human Doings” is to “do” the things others have taught us to do. Our community has shaped us: Our parents, our friends, our culture, our past, our schools, our contacts, and our co-workers.

Not everything I do is necessarily good for me, but I do these things anyway. I eat too much, I drive too fast, I get angry, I avoid awkward moments…Let’s just say I’m not perfect. My wife of 33 years is still working on me.

As a people group or a culture, we do try to influence change in others to allow them to meet their potential or at least prevent them from harming themselves or others. In some cases, we just try to encourage people overtly or indirectly to behave or dress within patterns of what is expected by the culture. We do this to our children, our friends, and our neighbors. Whether we admit this or not, we do try to influence others towards “good” behavior.

Coon Lake Road is a twisting road that connects my township to the “massive” city of Howell. It is a dangerous road for many reasons: Deer, falling limbs, road hazards, and the most annoying speed traps. 45 miles per hour is the standard. 60 miles per hour is the local custom. I’ve been stopped at least once on this road.

Yesterday I was driving on Coon Lake Road on my way to Grand Rapids. As I was speeding down the road, I was met with on-coming traffic with flashing lights. One car then two then 3 more – all of them providing me with the same visual clue – slow down if you want to avoid a ticket – speed trap just ahead.

So as a culture of drivers, we do this for each other: We send out visual clues of danger that is lurking in the woods just off the road. We tend to try and help each other as we travel. So when I passed the speed trap (going 45), I returned the favor to the next series of cars headed toward the speed trap – flashing my lights as I went. DANGER ahead!

So here’s my point: THIS IS WHAT WE DO AT PILLAR – We Flash our Lights! In our collective past, we have traveled down the same road of failure for too many years. We have been witness to patterns of development that result in failure. We have participated in the writing of massive requirements docs. We have been guilty of coding without a test harness. We stand guilty of just pushing crappy code out the door. I stand guilty of all of this and more.

So we can’t help but flash our lights! We see others heading down a path that will yield failure and we try to help by flashing our lights. We try and get the attention of those who continue to walk down similar paths of doom. Some heed the warnings and begin to introduce cultural change, others choose to ignore the flashing lights; they will pay the fine and continue without much regard for their crime.

Coon Lake Road taught me something about myself. I am willing to allow others to alter my negative behavior. But more than that, I am overly anxious to get in front others to effect change of their behavior – for their own good.

You see, a great revelation of truth demands a great response. I appreciate the truth that has been spoken into my life, but I also sense a great responsibility to speak back into the IT community a set of practices that will bring great benefit for others. The agile practices that we believe in do in fact provide for a measure of safety. They collectively save time and money as projects are developed. Beyond that, they encourage a responsible community of developers to bridge the fractured bridge of hope and trust to our shared business communities.

“Test Drive” everything safely. Allow others to teach you. Teach others what you have come to know and value. Do what you know is right – even when others try to knock you off the path. Keep your eyes on the road – flash your lights as needed.

So what is it that we do? This is the question that I find myself constantly answering. My kids ask me, my neighbors ask, and our customers ask me all the time; I think I have finally found an appropriate, although simplistic answer to the question: “We prevent the accumulation of Technical Debt”.

Yes, it is true we write great software.

Yes, we are a Test Driven organization.

Yes, we focus on bridging the gap between Business and IT.

Yes, we focus on Value first.

Yes, we embrace a set of practices that drive our daily and weekly disciplines. But we do so for one simple reason – the prevention of Technical Debt.

When I compare what we do at Pillar with the many other organizations, it usually comes down to the set of practices that allow us to identify and eliminate Technical Debt before it becomes a burden.

Technical Debt is the cancer of the IT world. It is in the database schema in form of tables, indexes, columns that are not used. It is in the extra code that was written that was not needed. It is found in every method or object that was written without a test harness. It is most often found in the 800-page requirements document that embodies the vain attempts of humans to capture business requirements. Technical Debt is the nuisance of society. It is the reason for batch programs to fail at night. It is the reason many programmers loose their hair. Yes, Technical Debt is the evil cancer of our profession.

So it comes down to this simple goal – the early identification and elimination of Technical Debt.

The Agile Practices that we embrace allow us to gain a competitive advantage over those who do not share this world-view. Our understanding of Technical Debt allows us to keep our attention on this age-old problem. If you don’t care about the consequences of Technical Debt, you tend to not worry about its impact. Some people prefer to just allow the next generation of developers to worry with the debt. We cannot assume this position – Our devotion to error free code will not allow it.

Pillar’s success is rooted and established upon the belief that the early identification and elimination of Technical Debt is in fact the pathway to lower overall cost of software construction and longevity.

So there you have it. That’s our secret. I wish I could have a better explanation, but I really believe that it comes down to this simple fact: We achieve our overall success by focusing on the elimination of Technical Debt.