There are two main ways to create mobile applications. The following post lays out advantages and disadvantages of both approaches.

Native Apps – applications that are installed directly on smart phone devices (iPhone, Android, Blackberry, etc.).

Advantages

1. Cool Factor – “There’s an app for that.” Being in the Apple App Store or Google Android App Market is great marketing for an organization.
2. Application Icon – When an app is installed its icon is placed onto the user’s smart phone desktop.
3. Experience – Native apps are generally faster and more fun to use.
4. Hardware Access – Native apps can easily take advantage of a smart phone’s GPS or camera.
5. Offline Mode – App features can be developed that do not require an internet connection.

Disadvantages

1. Many Platforms – Each application is unique to its platform. For example, an iPhone app will only work on an iPhone. If you want it to also work on a Blackberry, you will need to create another application tailored to Blackberry. New frameworks are being developed to help ease this pain.
2. Many Versions – When a new version of an existing native app is released, the users of the native app will need to download and install the update. People are not forced to update; therefore there will be multiple versions of the application in production.

Mobile Friendly Web Application – web application that is easily viewable and usable on a smart phone.

Advantages:

1. Reaches everyone – Anyone that has an internet enabled phone can view the application.
2. Web application already exists – If a web application already exists it can be updated to accommodate mobile phones.
3. One Version – Updating the website updates all the application users.

Disadvantages:

1. Not as cool – There is no app store or app icon. You need to access that application through your mobile browser.
2. Must be online – The application only works when you have internet connectivity.
3. Limited hardware – Although it is technically possible to access some smart phone hardware from a website, it is not as seamless.
4. Optimized look and feel – Each smart phone has its own look and feel and screen dimensions. Optimizing the web experience for specific smart phones requires implementing various mobile stylesheets.

The correct approach in any given situation depends upon the experience you are trying to achieve. It is important to note that this decision is not mutually exclusive. In some cases it makes sense to do both.

For the last 10 years, Atomic Object has been a pioneer in agile software development. During this decade, we have produced hundreds of projects for over 100 satisfied clients. Why so satisfied you might ask? Aside from our freshly popped popcorn, it’s because we consistently deliver high quality software in a highly predictable timeframe.

These attributes have not gone unnoticed. We have become known for this strong process that really produces great work, and it has become commonplace for customers to request agile training for their own development teams. We’ve done this training in the following two ways:

1.) The Traditional Approach

The traditional approach is what most people think of when they hear the word training. In this approach we identify the aspect of “agile” that the customer would like to learn about (i.e. testing, velocity tracking, simple design, pair programming, etc) and then craft a course that meets the request. These courses are usually week-long engagements that include hands on exercises. We have recently conducted a similar training in Baltimore.

Although these types of engagements are beneficial for companies, here at Atomic, we feel that there is an even better way to create a long-term sustainable change within an organization. This leads us to the second, preferred approach.

2.) The Integrated Approach

Integrated training is when we join the client’s development team for an extended engagement. These types of engagements generally last at least 3 months, which allows team members to internalize the concept, become comfortable with it, and then really apply it to the fullest extent – all under the guidance of experienced agile developers – and in their own code base. This approach commonly happens with companies that are trying to create a small agile team within a larger waterfall-centric organization. The approach here is to work directly with the client’s development team, creating software towards their current internal goals. During this time we also integrate our various agile practices. The beauty of this approach is that a team doesn’t have to take time off from development for training; instead, the training happens naturally while software is actually being created.

The main challenge that most clients face when adopting agile practices is not their willingness or ability, but rather, their organization’s ability to deal with the change. Being on the ground floor of this change allows us to innovate and modify process outputs to fit into the unique structure of the organization. An example of an innovation would be a modified burndown chart that more closely matches what the marketing department requires, or a tool that automatically generates high-level system requirements based on test output for the compliance department. We have found that these are the types of custom tweaks that are needed for a small agile team to be successful long-term within a larger organization.

In summary, integrated training is the preferred choice because:

1. The client team continues to get real work done while they learn to be agile.
2. Atomic helps customize agile process outputs to match the client’s organizational needs.
3. Management’s greater buy-in (longer engagement) signals their dedication to the training effort.
4. Better chance for long-term agile sustainability.

Atomic Object has always embraced the scholarly side of Computer Science. We encourage conference attendance and participation, writing for trade journals, and sharing technical expertise through our company blog. During the lunch hour, employees frequently give “brown bag” talks—presentations on a particular technology, problem, or methodology. When they’re not developing software at work, employees are expected to develop professionally, that is, to investigate new technologies and hone their skills. And before founding Atomic, our president, Carl Erickson, was a professor of Computer Science at GVSU, making it safe to say that AO’s had these scholastic sympathies from the very beginning.

Another symbol of our academic bent is our rather large library – yes, a physical library – of books, made available for use by Atomic employees. We have books on, to name a few, operating systems, system administration, visual design principles, agile methodologies, project management, and oh so many programming languages. In fact, our burgeoning library was outgrowing its space on our IKEA shelving, not designed to withstand the weight of such CS tomes as Knuth’s 3 volume set, The Art of Computer Programming. Also, the classification system was getting muddled, with newer books horizontally stacked atop older books being the only recognizable taxonomy.

And so we needed a new solution. Luckily for us, our Business Manager, Mary, has a background in commercial interior design and was able to use her skills in drafting to design an entire wall of built-in bookcases. With all the information radiators around the office, wall space has become an increasingly scarce commodity, so the final design left an opening for the whiteboard currently occupying the wall in addition to ample shelving. [Nerdy art history sidebar: The design references the facade of our building, symmetrical, with a large entablature supported by two engaged pilasters.] Our friend Ken Idema (of Ken Idema Builders) created the library shelves, continuing his habit of beautifying our space.

The lot of re-”cataloging” our books – unfortunately – fell on me. Lacking a technical background, you can imagine how mind-boggling it must have been to rely on reason alone to organize books on C, C++, C# and Objective-C. (Let alone Cocoon?)

With the help of a friend, the oversight of an intern, and a little sweat equity, we have made the library easier to navigate (usable) and gave it ample room for growth (scalable).

Through the process of moving and organizing the books, I became rather fond of these books so foreign to my own education – or were they? I couldn’t help but notice the prejudice for modern art cover designs among the books. They featured works by Pete Mondrain, Wassily Kandinsky, M.C. Escher, Georges Seurat (the connection of pointillism to pixels is a given), to name a few.

So please – admire with me the final product – an homage to order, learning, and to craftsmanship (of all kinds).

Adam Hartung made a simple observation in his keynote for Energy Summit 2010: markets shift; companies that don’t follow the shifts disappear.

As an antidote to obsolescence, Adam offered four pieces of advice: be future-oriented, obsess about competitors, disrupt yourself, create and maintain whitespace.

1. Plan for the future, not the past

It doesn’t matter what you sold or did last year. Don’t plan with a rearview mirror. You have no choice but to go where the market is going, not where it’s been.

Not surprisingly, this observation reminded me of Landmark Education’s teaching about the pervasiveness of the influence of the past. Facing a truly open future is a lot more uncomfortable and more difficult than living backwards with the market we already know and have had success in. The past provides data that can be analyzed; the future requires more guesswork. The past is known; the future is unknown. The past has already rewarded you; the future includes the possibility of failure. The past has known competitors; the future may have wholly new competitors.

2. Attack competitors lock-in

You don’t get new product insight from customers. Customers tell you they want what they already have, just cheaper, faster, better. Stop listening exclusively or too closely to your customers.

Adam offered several famous examples of significant innovations that came about by ignoring incremental improvement. Apple seems to be one of his favorite sources. (Apple and the iPod, Apple and the iPhone, etc.) He also offered stories about newspapers ignoring fringe competitors like Craigslist, Ebay and Google to their peril. The seemingly fringe competitors might be the ones that disrupt your business in the future.

This was the most interesting point in that it is in apparent contradiction to the idea of user-centered design. I think the contradiction can be resolved by moving your product research a level higher. Asking a customer what she wants might not give you valuable insights. Asking her what she cares about, what her pain points are, what her goals in life are, aren’t questions obviously related to your product, but may provide insights and ideas for innovation.

3. Utilize disruption to change thinking

Don’t find yourself saying, ‘That’s not a market we’re in; we need a partner.’

Adam’s best example here was Honda. Honda has developed a medical device to assist walking. This business evidently came about from their experience building industrial robots. They recognized that a walking robot was a big challenge that would cause them to learn. This lead to ASIMO, a humanoid robot that could eventually handle stairs. ASIMO lead to a walking assistance device.

According to Adam, Honda did this work in the medical device field without a partner because they’d “never learn” if they “had a partner.” This contrarian approach reminds me of the idea of beginner’s mind and how it might explain why frequent pair rotations increase development velocity. Learning drives innovation.

4. Disruptions open white space

Adam’s final point was that established companies need to create space for disruption and innovation to take place. Part-time assignments, teams from the corporate matrix, comparisons to existing products, short-term ROI—these aren’t conducive to disruptive innovations that may ultimately be highly successful.

In a New York Times article on lean startups, Steve Lohr describes how VC-scale money (say $5M) can isolate a startup from potential customers. The idea of a lean startup is to get a minimal viable product in the hands of customers as quickly as possible, learning as you go and adapting the product to find what customers really value. Agile software development practices support doing exactly that, and are a key component of the lean startup approach.

This is the approach Atomic has been preaching and applying for years with our startup customers. When you live and work in the Midwest you don’t often meet VC-funded startups. Our entrepreneurial customers are self-funded or angel-funded. The Common, Circle Builder, Realius and most recently Bloomfire are Atomic customers that exemplify the lean startup approach.

Reducing the cost of a startup from $5,000,000 to $500,000, assuming similar success rates, should ultimately create 10x the value. That would be significant for our economy and the pace of innovation. It makes me wonder… is there another order of magnitude improvement possible here? Can we take the next step to the $50,000 startup? Does first building a $50k application increase the success rate of $500k startups? Or does $50k just get you a prototype, not a company?

I don’t know all the answers to these questions, but I do know we’re wrestling with them every day. Maybe I should be smart this time and think of some good branding for the $50k startup. How’s “shoe-string startup” sound?

Writing about how awesome you are, or how great your company is, isn’t effective marketing according to Kathy Sierra (via Joel Spolsky’s recent (and perhaps final?) blog post). Sometimes you’ve just got to ignore this otherwise sound advice. This is one of those times.

I’m delighted and proud that Atomic Object was selected this year as a Michigan 50 Companies to Watch company by the Edward Lowe Foundation. The 50 to Watch award recognizes privately held, second stage companies that have demonstrated intent and capacity to grow. (For more on the award and foundation, see our press release.) Being one of the 300 companies selected over the six year history of the program exemplifies for me the two drastically different perspectives on Michigan’s economy evident since we started Atomic in 2001. On the one hand, we have the gloom and doom portrayed by the national media. On the other, we have world-class, growing companies like Atomic, DornerWorks, and Maestro eLearning (one of our customers, and the parent of Bloomfire). All three of these companies have been recognized as a 50 to Watch company in 2010. It may take a generation for Michigan to fully adjust to the realities of the global economy. I’m very proud that Atomic is a small (but growing!) part of that adjustment.

Atomic is more than the sum of its parts. It’s 10 years worth of learning, 10 years of earning customer trust, 10 years of sharing our innovations with the technical community, 10 years of figuring out our business on the fly.

But mostly Atomic is people.

Atomic today is 28 people. My co-founder Bill Bereza, without whom I might not have had the irrational confidence needed to start the company. Our first apprentice, Mike Marsiglia, whose broad talent now helps me with sales and finance. Karlin Fox, responsible for many internal innovations and holder of critical viewpoints. Micah Alles, who stepped up to the critical role of system administrator while maintaining his development leadership. Dave Crosby, our passionate and humorous first software craftsman, who was nearly there from the beginning and has mentored so many. Mary O’Neill, our business manager and my wife, who so adeptly wears many hats, all taken at one time or another off my head. Shawn Anderson, who always knew he’d return to the fold. Mike Swieton, one of our most flexible and thoughtful talents. Shawn Crowley, who’s moved us so effectively into product development practices, and who stepped up at a critical time. Mike Karlesky, who spearheaded building up our embedded work. Scott Miller, the first person with significant prior work experience to figure out Atomic was a good bet. Matt Fletcher, who shares my academic bent and has such high standards for himself. Patrick Bacon, with his incredible skills, steadiness, and positive attitude. Justin DeWind, who can tackle any problem, and inspired me to learn something about economics. Dustin Tinney, who codes with the soul of an artist. Drew Colthorp, who never acts like the smartest guy in the room, even when he probably is. Greg Williams, king of our embedded realm. Andrew Witte, our boy genius, all grown up. Greg Pattison, who so effectively expresses the critical project worry gene. Ryan Fogle, unflappable and productive like few others. Melissa Bugai, the first person in our office to carry the banner of exploratory testing forward. Michael Harrington, the most persistent apprentice applicant we’ve ever met, and thank heavens for it. Andrew Bellenir, keeping us safe from attack. Marissa Christy, proving the dictum of hiring brains over experience and spreading the word. Samuel Bowles, who is leading our growth in design. Kyle Gibson, the latest young developer to start down the path of craftsmanship with us. And finally, Paul Hart, who gives us a design pair and has already started teaching us.

I’m humbled and honored by the people I work with at Atomic. Being recognized as a Michigan 50 company is an acknowledgment of their abilities, hard work, perseverance and attitude.

Entrepreneurs and potential customers sometimes ask us to sign non-disclosure agreements (NDAs) as part of figuring out whether we can help them or not. We usually don’t sign NDAs at this stage of a potential relationship for several reasons.

The idea isn’t everything

We want to help entrepreneurs understand that “the idea” is not the critical factor to their success.

We’ve learned a lot from Paul Graham. Here’s what he says on the subject:

An idea for a startup, however, is only a beginning. A lot of would-be startup founders think the key to the whole process is the initial idea, and from that point all you have to do is execute. Venture capitalists know better. If you go to VC firms with a brilliant idea that you’ll tell them about if they sign a nondisclosure agreement, most will tell you to get lost. That shows how much a mere idea is worth. The market price is less than the inconvenience of signing an NDA.

—Paul Graham, How to Start a Startup

The cult of the NDA

We don’t want to perpetuate the cult of the NDA.

Sharing is critical

We believe most entrepreneurs would be better off sharing their idea with everybody and anybody to get feedback.

Sentence three of Paul Graham’s Startups in 13 Sentences is “Let your ideas evolve.” That can and should start before you’ve spent a dime on development.

Listening to our lawyer

NDAs are serious legal documents. Our lawyer says it’s a bad idea to sign one before we know the party well and understand what we’re promising not to disclose. He’s particularly not fond of NDA’s that are broad and general. We try to listen to him.

In the rare event that a potential client has genuine intellectual property that hasn’t yet been protected by filing for a patent (or maybe even a provisional patent) we can usually still have a valuable conversation without getting into trade secrets. We’re happy to sign the proper legal documents once we start working together.

The Michigan Agile and Beyond Conference brought 450 people together this weekend in Dearborn, Michigan to teach, learn and debate the broad subject of agile software development. The “beyond” part of the theme bothered me a little, for the same reason that it irritates me when I hear companies explaining that they do “practical agile”. Both statements miss the point that agile is about nothing more than delivering valuable software frequently and regularly. What can be more practical than that? Why do we need to move “beyond” that?

Ron Jeffries & Chet Hendrickson offered the best advice I heard all day in their opening keynote. Namely, to go beyond, you must travel through. Their point was that if you’re not in the “agile space” now, successfully using the core practices, then get there before you start tinkering or adapting. It reminded me of the debate in the early 2000s of whether you had to use all (then) 13 practices of XP to claim you were doing XP. Someone (might even have been Ron) responded that you’re doing XP when you’ve mastered all 13 practices and figured out which ones you need and how to use them on your project.

Chet cut straight to the chase when he said it matters what you do, because “agile isn’t any damn thing.” Ron followed that by quoting Emerson Codd: “The truth isn’t like a bunch of puppies running around where you chose your favorite.” Their talk was as casual, funny, and inspiring as always. They shared some of the simple truths about software development:

• Software development is all about people (Funny Ron quote: “When I got into computing, it was not with the intention of hanging out with other people.”) Tools can’t replace or compensate for people.

• Requirements need to get into the heads of the people building the software. Documents are a poor way of doing this.

• If you can’t ship working software every month, try two weeks. If you can’t do it in two weeks, try one week. You learn to build software by building and shipping working software.

• Waterfall doesn’t give you accurate information until it’s too late.

• If your software isn’t bug free, you can’t trust your velocity.

• If you’re manually testing everything your need for testers grows at least linearly with the number of iterations. You’ve got to automate some of those tests.

• If you can’t refactor, you can’t do evolutionary design.

They summarized by identifying the three non-negotiable core practices to being agile:

• Ship software regularly
• Test as you go
• Refactor to evolve the design

While their message, at least to me, was fundamentally one of “don’t forget the basics”, Chet and Ron also addressed the “beyond” part of the conference. They cited relationship to management, human resources, and dealing with projects that don’t fit in a single room as challenges that are still beyond the scope of accepted agile thinking. Ron called out Pillar Technology and Atomic Object as examples of companies pushing the boundaries of agile. They also reminded us that we have an obligation to share our experiments, both our failures and successes, to grow the body of agile knowledge. Chet added that these experiments push agile into new territory, but are still grounded in the simple statements of the Agile Manifesto.

Many times during the sales process we are asked to give a cost estimation based on our early understanding of an application’s core features. In order to responsibly and efficiently estimate, we conduct a 50/90 range analysis. We use this technique because we want to establish a responsible middle ground between our optimistic and pessimistic estimates. Our estimate is appropriately buffered for the risk we see in the defined tasks.

This spreadsheet is the tool that we use to conduct our analysis. Tasks can be estimated in any time duration that you choose (i.e. hours, days, weeks). At the start of a large project we generally estimate tasks in days or weeks.

I attended the tail end of Startup Weekend at The Factory this weekend. Kudos to Michael Boyink and Aaron Schaap for organizing this in West Michigan. Marc Nager, one of two people who run Startup Weekends all over the country, commented on the energy in the room and the incredible willingness of strangers to get behind ideas and work together. Evidently what we lack in VC we make up for in hard work and generosity.

The final pitches were pretty good considering that some of these ideas weren’t even hatched until Friday afternoon. An app for helping people keep track of things that need to get done even had a pretty functional backend implemented over the weekend. It was great to see eight teams and 40 or so people challenging the economic doom and gloom of our state, putting their ideas out there, listening to others, and taking action to make them real.

For a business that by definition occupies a highly technical domain, we have some relatively low-tech means of conveying information internally. Sure we e-mail, Twitter, Yammer, and even Skype with each other on a regular basis, but we also make use of yarn, note cards, cork boards, and old traffic equipment. I’m talking about our information radiators, objects around our office that align the team by sharing important information in a fun and hard-to-miss way.

Read the rest of this entry

Last weekend I had the privilege of attending a UX Agile Retreat at Cooper. The retreat was an informal event where ~33 practitioners from the UX and Agile fields came together to discuss how we can better create effective and successful products. The event schedule was loosely defined and it self organized based on the trending topics. We used a variety of exercises and discussion techniques to voice our experiences, concerns and ideas to help build a vision of a better, collaborative future.

Where We’ve Been

The UX and Agile communities have been flirting with how they could integrate their practices more seamlessly and respectfully. Both groups respected one another yet remained uneasy about having to alter their respective approaches for an integrated vision and process. UX Designers were worried that some of their practices would be minimized or marginalized due to Agilistas’ strong belief of minimal upfront design. Fear existed that quality design would be sacrificed to the almighty iteration once an agile project was underway. Agilistas were worried about designers doing too much work up front without creating functioning software. Developers were ignorant of the UX Design process and the immense value it provides. Individuals, like Jeff Patton and Lane Halley, have been working very hard to increase knowledge and respect between the two groups. Anders Ramsey organized and dedicated himself to making last week’s event happen. He did an outstanding job. The UX and Agile camps are coming together because they recognize and respect each other’s dedication to the craft of creating high quality products.

Where We Are

Most of our discussions during the retreat focused on vision, values and principles instead of outlining a strategy for collaboration. I’m glad the group was able to remain focused at such a high level because good process stems from alignment and a mutually shared vision.

We took a stand that the “Us and Them” mentality is dead and that we have to move forward as “We.” Management and business processes have kept our groups apart in the past due to a focus on efficiency and a misunderstanding of what it takes to create successful digital products. Management often times does not know how to ask us for what they want, nor do they know how to properly manage creative teams. We believe that we can create better products more efficiently by focusing on being effective. We believe that effectiveness is increased by working together closely.

The Future

The new vision is forming. The retreat group is committed to evangelizing and furthering this vision. I left the retreat with strong feelings of alignment, momentum and excitement. We are the makers of amazing, complex things and we are taking a stand on how we’ll bring the dreams of others into the world. We’re building a case for businesses to employ design thinking at all levels, to focus on the satisfaction of their customers and and to let individuals who understand the creative process to manage it for effectiveness.

We’ve always believed in hiring for brains, attitude, and general skills. This approach has served us very well, and while we’ll often chat with candidates about their specific technology experiences, that’s not what makes the difference in deciding whether to make an offer or not. Until fairly recently we’d only had the opportunity to apply this approach to hiring developers. Last summer we branched out some—I’m happy to report our strategy works for hiring Art Historians as well.

Yes, the Atomic art collection had really become unmanageable. From our original piece (an early nuclear-inspired gift from an aspiring artist who was a friend of my partner Bill’s mother) to a cast off (and semi-scandalous) discrete nude painted by an anonymous GVSU art student, we were really in a quandary as to proper display, cataloging, and preservation of our art. Oh, and pretty much everybody was grousing about answering the phones, greeting visitors, and watering the plants, too. So we decided to go looking for someone to help with a few of these things. The trouble was, we almost certainly didn’t have enough work for a full-time person, yet we needed full-time coverage. [Nerdy sidebar – we recognized that this position was all about response time, not throughput. Since our profit hinges on high utilization, this took some getting used to.]

Read the rest of this entry

In the article What Really Motivates Workers, the January-February 2010 issue of Harvard Business Review reports on a multi-year study of top performance motivators. Between these five contenders:

• Instrumental support
• Progress
• Interpersonal support
• Collaboration
• Important work

progress was the top motivator by a large margin.

(Unfortunately, when the researchers surveyed 600 managers they found that most of them believed that “recognition for good work” was the top motivational factor.)

I think the study explains why test-driven development (TDD) is self-sustaining once mastered. Large software projects done in traditional fashion may go for months without finishing or delivering anything. That’s a hard situation in which to see progress, and hence un-motivating. The same project done with TDD results in a smaller system becoming functional more quickly, daily progress as you integrate your working code and tests with others, and even hourly progress in the form of the “green bar” of passing tests. Progress is more visible and more reliably and regularly experienced.

The author also found that the most de-motivating days were those where people experienced the opposite of progress: a setback. Anyone who’s worked on a body of un-tested legacy code knows how common it is to make a change and break something. Setbacks are a de-motivating experience made more common by the lack of any test control.

Developers are motivated by the progress TDD brings and shows them.

A long time ago, in my first career as a professor, I started a file of nice words. The file had compliments, positive comments from evaluations, thank-yous, etc—nice words people had written about me. I never found a use for the file, but it seemed like a good idea to collect the raw data. In 2005 I resurrected this practice for use at Atomic, with a slight twist: when a client says some nice words about someone at Atomic, I distribute these words to the whole company. I don’t know how important this is to individual Atoms, but it seems smart to acknowledge when clients go out of their way to say someone did an exceptional job.

The nice words are typically about extra efforts, smooth deploys, great communication, effective project management, personal caring or dedication, creativity, predictability, or responsiveness. Very rarely they contain a technical compliment (“awesome algorithm”, “great tests”). But those nice words are much less common than the actual frequency of technical excellence in our projects.

I think this is because the benefits from our technical work tend to accrue long after the work is done. By the time our testing has resulted in no downtime or no user irritation, everyone has moved on and takes quality for granted. No one thinks back to the root cause of the pain they don’t feel. There are new problems to solve, new features, or new projects. It’s very easy to miss a critical element of what got you to this point in the first place. Think about it. When was the last time you stopped and appreciated a piece of software that’s run smoothly for years?

By contrast, the stuff that does attract nice words is much more immediate. When you get a prompt mail or return call, you know it immediately. When you see a project managed effectively, you feel it right now. When someone makes an extra effort to hit a deadline, you’re aware of it. Creative solutions to problems shine as soon as suggested.

Something that accentuates the under-appreciation of technical excellence is that many of our customers are business people, not engineers or developers. The people who generate POs and sign checks might not even be able to directly evaluate the technical quality of our solutions. It’s an act of faith, unless they’ve been burned before, that good software design and testing will make their projects more successful and their lives easier.

Ironically, less disciplined developers who commonly let bugs out into the world may be more likely to get the technical kudos. After all, they’re performing the software heroics of late night, last-minute debugging and patching. It’s their technical ability that a customer is held hostage to and rescued by. Just like the actions that engender our nice words, these efforts are highly visible to customers. I suspect some developers even get addicted to the opportunity to be a hero and save the day through their technical prowess. This isn’t really in the best interest of customers, but if you’ve headed down the path of undisciplined, unpredictable development, you’re probably thankful for the effort.

Heroics are great when they’re needed, but it sure is better to not need them at all. Guess I should go spread some nice words about all this great code I’m surrounded by.