If you tell me you are an Agile team, I assume that you are following, or at least trying to follow, the values and principles outlined in the Agile Manifesto. And I can easily verify how true you are being to those values and principles and to what extent you are achieving agility pretty quickly. Usually a 5 minute conversation about your team is enough to know where you lay on the agile spectrum. The Agile Manifesto creates a sort of measuring stick against which you can evaluate the agility of a team.

Even if your team isn’t practically perfect, the values and principles from the Manifesto are your goal. I know that you are doing your best to embrace agility, but sometimes the real world gets in the way.

While participating in the “Architecture and Collaboration” panel at Saturn2012, Rick Kazman made an interesting comment that I let slide at the time. In response to the difficulty of getting stakeholders together to talk about architecture, Rick commented, in summary, “It turns out this is pretty easy. We all have the same goals. People want to make the system work.”

This got me thinking about my development life, with and without Agile. Sure, everyone has the same goals – or do they?

The Agile teams on which I’ve worked had a clear goal, a clear purpose – to deliver value to our customer in the form of working software, quickly and predictably. Every decision that we made, no matter whether we were stuck in the weeds of a difficult technical problem or discussing high level methodology concepts, was made with this goal in mind. It always comes back to the software and how our actions would affect our ability to help our customer.

The teams on which I’ve worked that were not Agile, on the other hand, have always felt rudderless in retrospect. We had the same general goal of delivering software, but the focus on value was lost somewhere. The end result was usually disastrous. Little or no focus on quality. Process was either non-existent, which made the team unpredictable and unreliable, or so onerous that it actually prevented effective work. Some of these teams had fallen into the trap of jumping on the agile buzzword bandwagon without truly believing the values. Others were simply ignorant of the ideas.

On both the Agile and non-Agile teams, everyone did indeed have the same general goal of making the system work, as Rick pointed out. The teams that didn’t actively embrace Agile ran into problems with how they went about achieving that goal. Without a common set of core values guiding the team, team members lacked the tools necessary to reach the goal effectively. It was like knowing we wanted to go north but not having a compass to show everyone the way. One person would use the stars, others the sun, and still others the moss on a tree.

The Agile Manifesto is a guide, a compass, a rough measuring stick, a rallying point for teams who want to build great software effectively. The Agile Manifesto for software development gives teams… attitude. And it’s a flag for letting others know what your team stands for and how your team chooses to work.

I’m not saying your team is hopelessly lost if you don’t subscribe to the ideas behind the Agile Manifesto. I’ve been successful with and without practicing it. The difference between the teams that were successful and the teams that were, was that the teams that were successful had a core set of common values uniting the team while we worked toward our goal. Embracing Agile’s values and principles makes it easier to start this conversation and is a great starting point.

The big problem is that most teams who aren’t Agile don’t bother thinking about this kind of stuff.

Without a set of core values and principles, how the project ends up is anybody’s guess. No guide, no compass, no measuring stick for understanding how well your process is working for your team. There is nothing for your team to rally around other than perhaps some corporate sayings or a strong personality on the team.

So this begs the question. If you are not Agile… what are you?

Extreme Programming’s system metaphor, as traditionally presented, has a fatal flaw. It has a nudge which encourages teams to describe the system at too high a level, as one large monolithic thing. The result is nearly always the same: a generic metaphor that doesn’t really describe the software and provides next to no guidance for implementation. This has led many in the Agile community, including Kent Beck, XP’s creator, to abandon the system metaphor entirely. I have three big worries with this.

1. While Beck may have changed his mind about many practices from XP, both versions of Extreme Programming, available in two editions of Extreme Programming Explained, are readily available and actively promoted by the publisher.  Treating both editions as equals curbs the adoption and spread of better practices.  The metaphor lives on in spite of being abandoned by its creator.
2. Agile teams, while improving, have been generally slow to adopt now common knowledge on software architecture.  Deemphasizing the system metaphor has created a black hole in the software lifecycle around architecture and design.  Those teams that are software architecture-focused have a hard time figuring out how to remain agile while incorporating architecture best practices.
3. Metaphors aren’t going anywhere.  They are a natural reaction to describing complex things – in literature, in life, and in software.  Ignoring the system metaphor makes it more difficult to use effectively.

So rather than fighting the metaphor as a tool for describing software architectures, we should embrace it.  It’s time to refresh the system metaphor by combining current best practices from software architecture with what we know works for metaphors in literature.

The System Metaphor, Refreshed

The ultimate goal of the system metaphor is to create a common vision and vocabulary for discussing and reasoning about a system – with all stakeholders.  This stands for the refreshed system metaphor too.  Communication is king in the abstract world of software architecture, and so communication is the ultimate metric for determining whether a system metaphor is good or bad.  Metaphors that enhance communication are better than ones that confuse or mislead the team.

To this end, there are five guidelines for evaluating metaphors to determine their fitness as aids for describing software architecture, and one corollary for sharing and using metaphors.

A good metaphor:

1. Represents a single view.
2. Deals with only one type of structure.
3. Gives clear guidance concerning design decisions.
4. Sheds light on system properties.
5. Draws on a shared experience.

The system metaphor is one of the 12 key practices from XP and it is probably also the most controversial. Researchers at the Software Engineering Institute have observed that, of all the practices from Extreme Programming, the system metaphor is used the least. Other research done on graduate students at Carnegie Mellon concluded that natural language metaphors are useless for either communication or architecture design.

These are damning findings for the system metaphor, and yet on nearly every technical team with which I’ve built software, natural language metaphors were a daily part of how we communicated with each other. Maybe it has to do with the inherent abstractness of software, something that can’t be touched or tasted, only described. Maybe my teams have simply lacked the technical vocabulary needed to communicate in more precise words.

In spite of this nearly all of these projects were successful. Certainly there must be some merit in using natural language metaphors to describe a software system?

This got us thinking. Metaphors frequently come up in our everyday lives quite naturally and they are used effectively in books and movies. Is there something special about software that makes metaphors not work? Why would folks have such a hard time applying the system metaphor in practice when it’s obvious that metaphors in general are so effective in other places throughout our lives?

The simple answer is that we’ve been doing it wrong this whole time.

There’s nothing wrong with the system metaphor. It’s our application of the technique that has been wrong.

What’s missing from the prevailing literature on the System Metaphor is clear guidance that shows what a good metaphor should look like. Without this guidance, and without the background in software architecture to backfill this knowledge, teams are left alone to cobble together our own metaphors based on the limited information available on the Internet; a web of information that is largely an echo chamber of the same few sentences from the XP book. It should be no wonder that the system metaphor is unsuccessful in many cases.

What does a good metaphor look like? How do you know if you’ve created an effective metaphor? When should you create or update a metaphor? Why is one metaphor better or worse than another metaphor?

In looking for answers to these questions we combined what we knew about literary metaphors and software architecture practices to come up with a clear set of guidelines for the System Metaphor. These guidelines completed the System Metaphor definition and provided us with the guidance we needed to effectively design, analyze, and communicate the architecture of the software system we were building. We were no longer fighting our natural tendencies to create metaphors but instead were embracing them. And we created a more solid architecture as a result.

Interested in hearing more? If you’re going to Agile2011, why don’t you come to hear my talk? During this session I will explore our six guidelines for making better metaphors and walk through examples from our project. In only 30 minutes you’ll learn how to make metaphors that matter to your project, your team, and the system you are building in a way that improves team communication and encourages architectural thinking. This is a session you won’t want to miss!

Every 5,000 miles or so I take my car in to the shop for an oil change. It’s part of the routine, preventative maintenance I do to keep my car running in tip top shape. Routine maintenance gives me the peace of mind that my car won’t leave me stranded somewhere, extends the life of my car so I’ll get the most out of it, and makes sure my car is always functioning effectively which is extremely important with gas as expensive as it is. Routine maintenance just makes sense – cars are expensive and mine plays an important role in my day-to-day life. So it is only logical that I would want to take good care of my car.

Routine maintenance is good for other things too. I go to the dentist twice a year for a routine cleaning and inspection to make sure my chompers are in good form. I remove the cruft from the gutters on my house once a year so they don’t clog and cause bigger problems. I take my dog to the vet for blood work and a general checkup every year for her birthday to make sure she stays happy and healthy. I don’t want to lose my teeth. I don’t want the gutters falling off my house. I don’t want my dog getting worms or licking my face with bad breath. Regular checkups and maintenance help me avoid these things.

Routine maintenance is important for software teams too. Part of the total cost of ownership for any software development team is the cost of the routine maintenance that keeps that team healthy, happy, and working at peak efficiency. The last thing I want is for my team to break down in the middle of an iteration. Even a team failing to live up to their full potential is something that can be avoided with simple routine maintenance. Burnouts, flare-ups, missed commitments, firefighting – these are all signs of wear and tear that must be repaired to bring a team back to center. Wouldn’t it be easier just to avoid all that though? Preventative team maintenance is the single most cost effective way for ensuring teams have a full and happy life, operate effectively, and won’t break down at critical times such as in the middle of a project.

Teams don’t have oil to change every 5,000 miles, but there are still activities that should be a part of every team’s regular routine maintenance plan. Here are some of the things I’ve found useful on my teams.

Retrospectives and reflection – This is the oil change, the physical, the teeth cleaning of the software development world. Every member of the team gathers to think about and discuss how their practices are actually working for the team and project.

What do I do? At its most basic, a retrospective is a ritualistic, round table discussion where everyone on the team has a chance to share their thoughts and feelings on how the team is doing. Agile Retrospectives” by Esther Darby and Dianna Larson is a great reference for getting started with team retrospectives.

How often? Retrospectives should be done once every iteration, generally at the end. If iterations are long it might be worth considering doing them more often. If using a continuous release schedule, pick a date every 2 weeks to 3 months to reflect as a team even if you use continuous improvement practices.

Exploration – Always doing the same thing day in and day out creates ruts in our minds and spirits. Most people who are great at developing software will get bored if left to do the same things for too long.

What do I do? Toss things up by letting folks try new things. This might include running an experiment with a new technology or methodology, learning or taking full responsibility for a new-to-you team role, or taking on non-development tasks like writing documentation or coaching. Carefully consider risks when exploring and mitigate appropriately to ensure you still satisfy your threshold of success.

How often? This depends on the team. One tool I’ve found useful for understanding how prone to exploration teammates might be is the VIEW Problem Solving Style assessment. Retrospectives coupled with solid software risk management will also help determine the right amount of exploration.

Upgrade tools – Sticking with old and busted when there’s a new hotness available not only makes us feel unprofessional but can also hurt us.

What do I do? Buy the best you can within the technical constraints of your project.

How often? Upgrading doesn’t have to happen with every new release. There is a diminishing return by upgrading too often. Major upgrades that only happen every few years for tools that are your team’s lifeline (like, say, Visual Studio) are a great candidate for upgrades. For less critical applications like Office you might skip releases. And if the team says a tool is critical then don’t give them a hard time – figure out how to meet their needs!

Quality downtime – Vacation and holidays, time away from computers, projects, and even each other helps keep the team fresh and ready for work.

What do I do? Encourage folks to leave the office every once in a while. Part of this is culture – make it OK to go on vacation and *Gasp* not check your email! The big trick is that this needs to be quality time off, not just time away from the office.

How often? At least 4 weeks a year, more is better. That’s enough for the standard American bank holidays plus another 10 days. Time off should be taken in good size blocks, spread out throughout the year (keep in mind that American holidays are sparse throughout the spring/summer), and preferably not interfere with day-to-day team operations. With enough forward notice, anyone should be able to take a vacation whenever they want.

Status meetings (with visible progress) – Check the pulse and blood pressure of the team.

What do I do? Get together to review progress, risks, tasks, sanity, problems, and make sure there are no big surprises. The key here is to get a real sense of the important things the team wants or needs to track. Big visual charts are great for this – use data when possible to show real status. A round table will catch the outliers that can be challenging to measure.

How often? Generally a one hour weekly status meeting is enough, even if you’re already doing daily stand-ups.

Parties, downtime together – Take time to celebrate your successes! A team that parties together is a team that builds great software together. Do things with your teammates other than writing software.

What do I do? The sky’s the limit – happy hours, LAN parties, hikes, concerts, dinners, lunch. You don’t have to have the whole team for every event, but folks should feel comfortable hanging out together. Designate a social committee to come up with fun things to do or make it a team role that moves around.

How often? At least once every iteration or once a month. Just go have fun and you’ll be OK.

What else?

Look, you’re going to pay to keep teams working one way or another. Either you’re team will break down and you can pay to rebuild it (which may not always be possible) or you can set aside the time and resources to do the routine maintenance. You don’t always get to choose when a catastrophic breakdown will happen, but you do have the choice of when to schedule your next oil change. Retrospectives are a no brainer – just do it.

When building relationships we look for commonalities between ourselves and others. When we have things in common it makes us feel good, like we’re not alone in the world. And the things we have in common become the basis for lasting relationships. Homogony in a group brings comfort, you know what everyone else is thinking, you can predict how the group will react to new ideas, and you become confident, even emboldened because you are surrounded by people who are similar to you. Let’s face it, it feels great when you share a new idea to nodding heads of agreement and a strong show of support from your peer group.

Over time you’ll find your niche, a great group of people who think like you and see value in the same things you do. The more time you spend together the closer you’ll become and the more awesome your community will get. You’ll feel supported and you’ll give support to your peers. Together you’ll build an exclusive community of trust, mutual respect, and consensus; one that feeds on itself with demonstrations of perpetual support free of criticism, negativity, and ridicule.

With a large enough group, it’s possible to warp reality around yourself so that you are only exposed to the ideas and feelings produced by your group, the place where you feel safe, comforted, and welcome. With so much support it is easy to dismiss ideas created outside the group as “radical” or “stupid,” and miss out on huge opportunities in the process.

This mentality is everywhere in the software world.

The software craftsmanship movement largely molded by Pete McBreen in his book pitted the enlightened craftsmen against the ignorant engineers. I strongly identify as a software engineer and was duly offended by this book. It wasn’t until about mid-way through the book, when McBreen suggested that the Personal Software Process was one of the greatest processes a craftsman could use that I realized we agreed more than we disagreed. A line in the sand had been drawn and two groups formed but there was more overlap between these groups than anyone was willing to admit. As an engineer I don’t want to “sweep the shop floor” as someone’s apprentice but I recognize the importance of mentoring. Software Craftsmanship highly values the contributions of the individual but recognizes that teams must somehow be organized so projects can succeed. Software engineering (at least as I’ve always thought of it) and software craftsmanship are nearly identical ideas and McBreen’s book reads as a jaded rant produced after an unfortunate project. Two communities with similar passion and ideals, divided by a label!

Agile and architecture are two other groups that (only until very recently) seem to ignore each other out of spite or perhaps ignorance. The main principle of the agile movement is a focus on delivering meaningful software that helps solve customers’ problems: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” The Software Engineering Institute has spent the better part of two decades researching software architecture and how it affects a team’s ability to deliver valuable software to customers. Software architecture is a communication and organization mechanism. The primary purpose is in helping teams deliver software effectively. It is a means to achieving the very same principles outlined in the Agile Manifesto. There’s nothing wrong with documenting a design, writing down quality attribute scenarios in addition to user stories, or making a plan before your start laying down production-quality code. It is true that the wrong kinds of up front design will do more harm than good for all but the most trivial systems, but that doesn’t make all architecture practices as bad as agile zealots will have you believe.

Is Kanban agile? Who cares?!? If the process works for your team then use it! The more important (and interesting) question we should be asking is – how do I know if my process is working?

As someone who regularly experiments and actively seeks innovation, I’ll be the first to admit that I get things wrong often, but I pride myself on not allowing my likes and dislikes, my preconceived perception of my reality, to get in the way. While I don’t enjoy leaving my comfort zone, I recognize that it is important both for personal growth and the growth of the communities in which I participate.

And when it comes to building software, I recognize that though I may have a preferred approach or process, and set of tools and languages I like, there is no one-size-fits-all solution and the most important thing is to use the best tools for the job at hand. While I may have strong beliefs they are weakly held, my one conviction is to always do what I think is best for the project and the people involved with it.

If you were to go to two improvisational jazz performances, even two concerts by the same band, you’d hear different music at each show. The thrill of experiencing something unique, as it is created, without any kind of real plan or rehearsal, is both exciting and entertaining. Sometimes the music is so spectacular you feel like you’re witnessing a miracle. Other times the group can’t seem to get it together and the show is one long, painful indulgence in artistic expression. No matter the outcome, what you hear during that performance will never be experienced again.

Music has always served as a great metaphor for thinking about software development. At XP2010 during one of the most original key notes I’ve ever seen, Bjørn Halterhaug and John Pål Inderberg, professors of musicology and improvisation respectively, from the University of Technology and Science in Trondheim, Norway and both veteran jazz musicians, discussed, through music and words how they approach improvisational jazz, the mechanics for making it work, and the general implications on collaboration among artists. It’s tempting to romanticize improvisational jazz as a truly spontaneous creation but this isn’t exactly how it works in reality. For any improvisational jazz band to be successful its members must exhibit seven key characteristics.

1. Provocative Competence Interrupting Habit Patterns
2. Embracing Errors as a Source of Learning
3. Minimum Structures that allow Maximum Flexibility
4. Distributed Task: Continual Negotiation toward Dynamic Synchronisation
5. Reliance of Retrospective Sense Making as Form
6. Hanging out: Membership in Communities of Practice
7. Alternating between Soloing and Supporting

I propose that these seven characteristics apply directly to how teams who espouse emergent design should approach software architecture.

Music and Design

Experienced musicians have an attenuated ear which enables them to hear music in ways that novices can’t. Drawing on a well-developed playbook of clichés, an expert in the standup bass for example can not only follow the minimally, well-defined structure of a song but also weave pleasing bass licks into the musical ramblings of his band mates, adjusting his actions based on the paths his band mates choose with appropriate responsiveness as the song develops. Part of it is musical maturity, a taste or style developed over years of playing, part of it is also trust both in himself as a musician but also in the rest of the group, that they too will not overreact to mistakes and are also able to follow a musical flow as it develops.

Well-defined but minimalist structure. Contrast this with the music played by a symphony which is also well-defined but has explicit and detailed structure.

When I hear this I immediately think of architecture as seen through the lens of agile software processes which advocate strongly for emergent design. Agile software development processes and agile culture in general strongly encourages teams to become improvisational architects. Create a minimalist, well-defined design of the system and then allow the developers to evolve the system, creating the design as they develop, playing off the code written by their fellow teammates as the system emerges. The romantic view of this is appealing to some: “Let’s go have a code jammin’ session, you dig?” But the results of an emergent design can be just as varied as improvisational jazz bands; some designs are elegant and spectacular successes, some designs are flaming piles of disaster, most turn out somewhere in between – usually good enough for customers who aren’t paying too much and who expected a somewhat unpredictable but functionally adequate outcome.

So if you enjoy the thrill of experiencing once-in-a-lifetime moments of creation, the outcome of which can never be predicted or known ahead of time, then emergent design is probably right up your alley. As demonstrated by the near exclusive emphasis on code and shipping, many agile developers fancy themselves as code jammin’, improvisational architects.

The exact opposite of emergent design, of course, is the easy to hate (and rightly so) enemy of creating things that actually work, Big Design Up Front, where a heavy cost is levied against a project in the beginning without producing any usable code whatsoever. Sticking with the music metaphor, the well-defined, explicit, and detailed structures of a symphony might take a composer months or even years to create. But in exchange for this planning you get a piece of music that is guaranteed to be executed (for all intents and purposes) in a nearly identical way in every performance in which it is played. I am not saying you should use a Big Design Up Front approach, in reality, even Mozart tried out music and made incremental deliveries to his sponsors as he wrote.

While certainly a degree of improvisation happens when we develop software, customers paying for software usually expect more predictability in the outcome. So, while it might be ok to spend 30 bucks for a fun first date with a girl at a jazz club – if only for the experience of it – when I pay 100 bucks a ticket to see the symphony play Mozarts’s Requiem, I would be more than a little disappointed, angry, and confused if the first chair violinist “felt a groove” in the middle of the second movement and began jamming. The greater the cost of a project, the more highly valued predictability in it will be.

Who can be an Improvisational Architect?

Mozart was a true genius, a master of composition. To play Mozart, you need to be well practiced but you don’t need to have his level of genius. On the other hand, most members of a great improvisational jazz group must be experienced musicians – experienced in composition as well as technical playing ability. Even then, a great group will usually avoid disaster but occasionally it will still happen because of the nature of improvisation.

In my experience, teams that plan to allow their designs to emerge do an ok job of providing the minimal structure that is essential for evolving a design. But only a few developers have the necessary experience and background to truly improvise a design. The implication? Most teams are terrible at improvising architecture because they have neither a solid enough understanding of the core fundamentals for software architecture nor the experience with using architectural design to reason about a system.

I believe that most of the seven characteristics of improvisation are deeply ingrained in agile culture, but agile teams often fail to fully embrace all seven characteristics of improvisation when designing a software system. A team without the experience, who doesn’t understand design cliché’s (architectural styles and patterns) will have an unpredictable outcome when allowing the design of a system to emerge as the system is developed. This is something the agile community must work to resolve.

Bonus

Cory Foy was thinking ahead and had the foresight to record video of the performance/keynote.  It comes in 6 parts.

• Part 1 – introduction number
• Part 2 – introduction to improvisational jazz, link to XP, perspectives and group dynamic, a glimpse of how they teach jazz and improvisation
• Part 3 – Second number, application of theory discussed in part 2
• Part 4 – Beginning to introduce the idea of minimalist structures, awesome body percussion number
• Part 5 – communication, the seven characteristics of improvisational jazz, demonstration of “minimal structure for maximum flexibility”
• Part 6 – closing remarks and the final number

Ingvald Skaug was also inspired by this talk and wrote an interesting essay which explains kanban as agile jazz. Check it out for a process perspective on the idea of “minimal structure for maximum flexibility.” If you believe Conway’s Law, then it isn’t coincidence that we would apply the characteristics of improvisation in jazz to both process and design.

I used to think hacking was bad. It was something you did when you didn’t have a plan, when you didn’t know what you were doing; it’s what amateurs do, noodling around the code without clear direction or intent. Or it was something you did, quick and dirty, just to get something out the door. Hacking is the best, surefire way to waste time and create mountains of unmaintainable code you’ll have to rewrite anyway. I’ve always struggled with this since I feel so drawn to hacking culture – DIY, playing with things just to see how they work, ignoring the instruction manual, reveling in the aesthetic of a job well done, making what you can within limited constraints – and many of the brightest minds in software development speak quite passionately about the merits of hacking.

Thinking about this for a while, I’ve come to the conclusion that there’s nothing wrong with hacking. Quite the contrary, hacking could be one of the most positive things a team can do. In fact, many of the agile processes and techniques that have worked for me in the past seem to be designed to cultivate teams of hackers.

It seems I had fallen for some of the myths about hackers.

Myth: Hackers don’t have a plan

Hackers do have a plan but they acknowledge that the plan will change and then plan with this in mind. This means creating plans only to the level of detail to which you are currently comfortable making plans. For example we all know that making a detailed plan at the start of a project, down to the code level, for all but the tiniest programs, is silly since the plan is mere conjecture of a positive outcome. Rather than writing a fantasy on paper, hackers lay plans based on the current knowledge. These plans then expose areas for further exploration (hacking!), the resultant knowledge of which can be turned into more detailed plans.

In XP these detailed plans are created just in time during the iteration planning game, sometimes even later than that. That’s not to say that there wasn’t a plan before the iteration began. Not so. A great degree of planning, communication, and coordination was required to be able to plan so adeptly, so quickly.

Myth: Hackers don’t know what they’re doing

In the literal sense, a lot of times hackers don’t know what they are doing. That is why they are hacking. The purpose is to figure out how something works or the best approach for something. And that’s the key. At a meta-level, hackers know exactly what they are doing – they are searching for information, for knowledge, for a means to achieve an end.

Action research is a relatively new-to-software-engineering research method that seemed to take agile researchers by storm at XP2010. The basic premise is that a researcher works closely with a consenting organization to observe practices in software engineering. Rather than acting as a passive observer, as is traditionally done, the researcher injects practices directly into the team and observes before and after reactions. For example, in recent work by Tor Erlend Fægri, having observed issues with team collaboration he suggested several techniques to help solve the problem. Some suggestions worked, some didn’t. Fægri was able to take the time to understand what happened and why because he was dedicated to understanding almost as a participant, watching the events unfold. This take on research makes me think of Jane Goodall’s work with chimpanzees in which she directly interacted with wild primates in order to better observe their behavior.

When I first heard about action research it sounded a lot to me like hacking – trying things out to understand how something works.

Myth: Hackers don’t create value

Yes, the code that comes out of a hard core hacking session might be a big pile of spaghetti, but consider the purpose of this work in context. Another perspective is that hacking may incur technical debt which sooner or later will need to be paid off. But it’s important to keep in mind that not all technical debt is bad. When you are hacking, you are either in learning mode or in finish mode. Learning mode is never wasted effort. Finish mode, where you are just trying to get something finished so it can be used, can leave scars on your code, but the immediate value provided to customers can be enormous. When you have a desperate and immediate need, anything that works today is better than something perfect that works next week.

The same goes for architecture. Of course, many of the architecture researchers use words and phrases like “experiments” or “trade-off analysis” to describe this same act of quickly creating something for the sake of knowledge. That’s really just hacking too.

Sometimes the artifacts you produce are throwaway. Sometimes the working solution is good enough and you’ll never have to worry about it again. Sometimes you’ll have to pay off the technical debt. But hacking for the right reasons is never wasted effort.

Agile Development Helps Cultivate Good Hackers

Agile software development, be it controlled through time boxes or flow, is all about ensuring that work doesn’t teeter out of control a day at a time. The focus on providing customers with value creates an environment that encourages action and creation. The agile manifesto gently nudges hacking behaviors. Frequent releases of working software, welcoming changing requirements, focus on simplicity and continuous attention to technical excellence, helping the customer understand what they need and then doing your best to make it for them. Even the idea of continuous process improvement is about hacking your team to make yourselves better. Hacking is the very lifeblood of agile software development.

Hacking isn’t a dirty word. Hacking could be the most important thing you do all day.