Scott Bellware

A Simple, Definitive Metric of Software Development Productivity

2011-03-01T08:22:00.007-06:00

Developer productivity is made of two components: 1-) the speed at which work is done when work is getting done, and 2-) the amount of time that is lost when anything stands in the way of getting work done, or more specifically, of getting "value-added" work done.

The most common mistake in measuring software developer productivity is the failure to take both components into consideration.

Productivity is what's left over when you subtract the amount of time lost to non-value-added work from the total time spent working. If you only ever measure your pace when doing value-added work, the results will be a massive over-statement of developer productivity.

Complicating matters further, developers' natural pride in workmanship can make classifying work as "non-value-added" a difficult task. Without an environment that is entirely supportive of transparency, learning, and improving, truthful measurements of productivity are just not possible. Far too many personal preservation mechanisms will get in the way.

The hard, cold truth about developer productivity is that a truthful measure of productivity on a typical software development team is in the 10% to 30% range. Getting a clear picture of the reality of software productivity on your team remains a necessary effort - even in light of the difficulties of undertaking it.

Non-Value-Added Work

Pride in workmanship is what keeps most developers engaged in the work, but it's a double-edged sword. Peter Drucker's famous quote applies: "There is nothing so useless as doing efficiently that which should not be done at all".

We have to come to terms with non-value-added work. We have to consent to it. Non-value-added work simply is.

If we're willing to consent to the reality of non-value-added work, then we'll be open to seeing it. Seeing it is the first step toward measuring productivity meaningfully, which is the first step to developing an action plan for restoring productivity.

If you can get comfortable with the reality of non-value-added work, then you can get comfortable with using its proper name: waste.

Here are a few things that we do that are waste - regardless of any pride we might have in the hard work and perseverance involved:

Teasing apart code to understand how it works, especially when this effort is repeated whenever a team member confronts that code
Performing deep and complex setups of data in an external system (or systems) in order to prove that changes to a local system are correct
Hiding distributed systems behind interfaces that pretend that remote objects are local objects
Failing to create transparency in objects' interfaces as to their underlying latency, or network and storage protocols
Creating development infrastructure, tools, or automation that is only readily-understood by people who have had extensive experience with them
Failing to properly codify or tag tests so that knowledge of which tests to run and how to run them when a change is made is obvious
Designing tests who's failures aren't definitive proof of either defacto functional errors or mistakes in setting up or operating up the test environment
Failing to recognize excess tests as coupling problems that obstruct needed design changes
Designing tests with either excess specificity, test granularity, or penetration into adjacent modules
Underestimating the destructiveness of ambiguity in any code or any other development artifact in general
amongst many other things that can appear as hard-won effort

In short, any work you do that isn't directly related to adding desired capabilities to the system is waste. Any work that you do to resolve obstructions to getting your work done is waste - even if that work improves the overall quality of the system. The reason is simple: obstructions are mistakes that you haven't yet learned not to make.

Some design challenges are due to unforeseen changes in direction in technology or business. As long as you can make those changes without also having to deal with negligent design choices and expediencies of the past, then you're still adding value. The moment you have to deal with obstructions to the work, you're incurring waste - no matter how attached you might be with the designs, mechanisms, and even human organizations and processes that underly the obstructions.

There may always be some waste in the work, but the presence of it doesn't excuse an aversion to seeing it for what it is, accepting that it's there, consenting to its presence, and developing the means to aggressively and progressively eliminate it.

Measuring Productivity

Here's how to get a clear, honest look at software development productivity:

The moment you're forced to divert to non-value-added work, write down the time. The moment you're back on track doing value-added work, write down that time. At the end of the day, add up all the non-value-added time and subtract it from your total work time.

Your work time shouldn't include things that aren't time spent on developer activities unless they're directly related to dealing with an obstruction. For example, a lunch break isn't non-value-added time. However, a walk to the break room to blow off the steam building up from dealing with frustrating design mistakes is counted as non-value-added time. A standup meeting isn't non-value-added time, but a meeting to address an obstruction or to resolve an ambiguity is non-value-added time.

You'll inevitably come across grey areas where some time spent isn't easily classified as non-value-added or value-added. This is especially-true of explicit improvement efforts. Discussing these grey areas with your team and coming to some conclusion is a valuable part of the larger improvement journey that you're on.

Make all the factors feeding your considerations explicit and come to the best decision you can for the circumstances you face. And most of all, understand that different circumstances might lead to different conclusions. Make these differences explicit as well. Open dialog and flexibility is an absolute must, but so is rigor. Keep an open mind (an open heart is also helpful), but be vigilant against allowing a discussion to become a zoo.

If you do a daily standup or status meeting, or have an activity stream app like Campfire, an IRC channel, or even email, report on your productivity every day. Even if you're the only person on your team undertaking the exercise (note: this isn't really sustainable), you can report your productivity.

The goal is to be transparent about the truth of your software development productivity. Once the truth is laid out for all to see, it has a chance of affecting the moment-by-moment decisions that you and your teammates make that continue to confound progress.

Next Steps

Wherever there's waste, there's an accumulation of excess complexity that encourages even more waste. The goal is to fix the design problems that cause it, and to restore productivity to sensible levels. And ultimately, to fix the processes that encourages the waste that exacerbates the design problems that take up long-term residence.

We have to remain utterly unattached to the efforts we invest in solving problems that should not have existed in the first place. If we're not capable of adopting such a disposition, we're incapable of harvesting enough learning about counter-productivity to restore productivity.

If you can measure your productivity truthfully, then you can work with your team to collectively improve the situation, and to continue to improve it.

The start of an improvement effort begins with recognition of a problem and a pathology. Being able to make measurements of the problem is essential to recognizing the problem and also to monitor progress. By developing the ability to recognize waste, you've also given yourself some basic tools to monitor your progress. Measurement might be a bit depressing at first, but it also becomes encouraging as you make progress.

The anatomy of an improvement effort is the subject for another day, but suffice to say that what you're trying to create is a Learning Culture. Doing this isn't a quick-fix, but undertaking it will yield some benefit immediately, and continue to yield a constant stream of value along the way.

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

Kaizen: "Relentless", Rather than "Continuous"

2011-01-18T08:52:00.005-06:00

"Kaizen" is usually translated from Japanese to English as "Continuous Improvement". It loses its power in the translation.

"Continuous" is perfectly reasonable and correct, but it doesn't really convey Kaizen as the underpinnings of a way doing work. Kaizen is certainly continuous, but it's continuous as a side effect. More importantly than being continuous, Kaizen is relentless.

"Continuous Improvement" can become a flaccid thing - yet another empty corporate mission. At its worst, it reinforces workers' cynicism about cultural initiatives that don't really make work or outcomes any better. "Continuous Improvement" is passive. It's even apologetic and deferential. "Relentless Improvement" is active. It's even fair to say that Kaizen is aggressive.

Often, the real problems robbing an organization of its productivity are the smaller, pervasive problems that are finely-woven into the fabric of the way that work is done and conceptualized. When you solve problems that are inherent in the DNA of the work (and consequently, the organization), you'll likely free up more resources than you might have imagined. A Kaizen culture understands that microscopic, pervasive rot causes a kind of osteoporosis in the bones of the work that can't be seen without actively hunting it with fine optics, or until the bones start to break.

A Kaizen culture doesn't wait for problems to show up. It looks for problems. It's imbued with an awareness that negligible problems often aren't negligible at all - especially when they're pathological and pervasive. It knows that pathological and pervasive problems are often charged with the greatest potential for destruction. Kaizen is literally "looking for trouble", knowing that if it doesn't, trouble will find it. It challenges its belief that these negligible problems are not worth effort or attention. It grounds its exploration in meaningful but practicable, and accessible measurements, rather than in methodology mysticism. In progressively learning what measurements are interesting and practical, it learns to ask better questions.

When a Kaizen culture doesn't see problems, it wonders first whether its vision needs improvement, and sets out to sharpen its eyes rather than rest on its laurels and dull its senses. The adage, "If it ain't broke, don't fix it", is a fallacy. Waiting for problems to come to you means that you're dancing to their tune. The downward, entropic cycle of fire-fighting and decay isn't transformed into a greater capacity to keep moving forward without constantly losing ground.

In the end, "Continuous Improvement" is useful because it's a standard term. But when it's time to actually do Kaizen, "Relentless Improvement" sets more realistic expectations about how it achieves pervasive dominance over pervasive problems.

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

Testing User Stories - Problem Development Before Solution Development

2010-10-28T08:45:00.032-05:00

User stories can be wrong. Business Analysts and Product Owners can be wrong. They can be the best representatives of user interests but they're often still proxy users. The most expensive mistakes to be made in software product development are made when we get the requirements wrong. A quick way to increases the risk of proceeding to solution development on the basis of incorrect requirements is to not prove that they're right. Or, in other words, to not test them.

The only way to definitively validate that the problem statements for a software product are right is to put the working software in users' hands.

User interviews, focus groups, simulations, and mockups are steps along the way, but their purpose is to reduce the time and cost of getting users in front of an experience that is immersive enough to validate assumptions. Allowing users to experience our proposed solutions to their problems clarifies whether the problem is understood.

Generally, we're taking too long to get stories validated - even in colloquial Agile development. Sending a user story through an entire development process in order to validate it is too much. In order to validate user stories, we need to collapse the solution development timeline so that feedback can be had without the expense of the solution development. We commit to the solution development cost once we've validated the problem.

There are two distinct (but inextricably-intertwined) steps that make up a development process that recognizes the value of reducing the time-to-feedback for testing user stories. The later step is the plain-old Solution Development that we use regardless of whether we recognize a preliminary first step. The earlier step is Problem Development.

Problem Development is software development. There's code. There's deployment. There's testing. There's design and analysis. There's process. There's just much more of it in Solution Development (even Agile development) than in Problem Development. And there are different kinds and variations of these activities in each. Problem Development is software development that works hand-in-hand with business development.

Problem Development and Solution Development have different goals. Problem Development is concerned with feeding Solution Development with input that has less risk (at a time when risk is the riskiest).

Assumptions are liabilities. User stories are assumptions until they're validated. To validate user stories, deliver software experiences that propose to solve the problems that user stories describe, and measure the feedback. There's delivery in Problem Development, but not final delivery.

Final delivery is a concern of Solution Development. Final delivery requires long-term sustainability. Solution Development is concerned with long-term sustainability. When we work toward achieving long-term sustainability before we need it, we end waiting until the longer Solution Development process plays out before getting feedback on user story validity. Which is too long.

Problem Development is concerned with short-term sustainability. The reason that it has to be sustainable at all is that the output of Problem Development is the input to Solution Development, and these two steps are ultimately one process that flows together.

It's far too easy to see Problem Development as "throw-away coding", but it's absolutely not. Problem Development is a way to manage some of the biggest risks in software development - risks that often go un-addressed and are frequently realized as wasted effort and resources, and lower productivity. This kind of risk isn't effectively managed with practices that are satisfied by "throw-away" code.

If throw-away code is the output of Problem Development, then Solution Development has to undergo a (mostly) cold start, benefiting from far less of the momentum created by Problem Development. It might be necessary to make the kind of tradeoff that creates these kinds of batch transfer problems, but making a habit of it is a path to a cumulative productivity deficit.

The kinds of practices that characterize Problem Development might look like software development heresy (or at least "Agile" heresy) to many disciplined solution developers. The realities of Problem Development mean that traditional aspects of Solution Development are short-circuited - after all, Problem Development is looking for a shorter circuit.

The Problem Development practices might even seem irresponsible, but recognize whether you're looking through a Solution Development lens. For just as Problem Development practices can seem irresponsible from a Solution Development perspective, applying Solution Development practices to the point in the timeline best suited to Problem Development can be equally as irresponsible.

Problem Development is about testing or validating user stories' problem statements. Solution Development is about building software based on validated problem statements.

The whole of development process is concerned with finding the way with the least wasted effort in getting from concept to cash.

Feeding un-validated user stories into the Solution Development transformer is often the most efficient way to increase wasted effort.

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

The Myth of Iteration 0

2010-10-25T08:45:00.035-05:00

"Iteration 0" is the initial phase on an Agile project when collaboration tools such as a source code repository server, a continuous integration server, and distributed build and test agents, as well as document tools like wiki servers, and other tools are set up. It's often also a time to configure individual workstations and team members' tools in preparation for everyone starting work.

"Iteration 0" is a bit of a popular misconception that is a side-effect of software projects initiated by technologists - which sounds a bit ridiculous at first. After all, who else but technologists to do software projects? Of course technologists are the right people to do software projects, but are all technologists the right people to execute project startup? And for that matter, what is "project startup" as differentiated from the rest of the work? Is it something that should be approached differently than the rest of the work?

The technology-focused project initiation isn't necessarily the wrong thing to do, but it's often only the right thing to do from within the technologist's perspective, and that perspective can be limited. A tool-biased perspective is a challenging thing to overcome by someone whose moment-by-moment work is necessarily suffused with a constant focus on tools, or whose initial career path passes through a lengthy time of tool focus.

If we literally codify the "first iteration" as "Iteration 1", we technologists can use a bit of geekery to make allowances for a pre-iteration focused on technology. As programmers, we're accustomed to counting a list of things starting from zero. If the list of iterations starts at the "zeroeth" position, but work is only scheduled to start on the first position, then we get an extra "unclaimed" iteration to work with: "Iteration 0".

Any way you cut it, the first iteration is the first iteration, regardless of the numerical designation assigned to it - and regardless of creative license and word games. If you choose to have a zero-based project schedule, then we should naturally change the schedule to state, "Deliver something user-valued in Iteration 0". Which, consequently, is not an invitation to technologists to insert an "Iteration -1" at the head of the schedule.

Over the past few years the caution to not exit any iteration having only shipped technology has been whittled down to a more technologist-friendly caution against exiting an iteration having only shipped frameworks. It's a narrower interpretation of a deeply-powerful principle. It sets the stage for the institution of a technology-focused "Iteration 0".

Nonetheless, it's sometimes necessary to devote a period of work entirely to technology concerns - especially if technology concerns become obstructions to user-valued concerns. And it's all too easy for technology to become an obstruction to delivery in a technology product delivery effort. But this isn't the problem with "Iteration 0".

"Iteration 0" is a project startup issue that is technology-focused startup rather than a product-focused project startup. There's an implicit assumption in "Iteration 0" that - while perfectly reasonable from a technologist's perspective - isn't necessarily an optimal path for project startup.

If a project startup is executed with "all hands on deck", then coordination of the people involved becomes an issue that must be dealt with right of the bat, including the setup of tools that support the coordination.

So, is it necessary to start a project with an amount of people that necessitates coordination and collaboration tools? If project startup is executed with a small workcell of skilled pathfinders, do they need the tools that necessitate the "Iteration 0" work? Can a project startup be executed without the need for the collaboration tool setup?

And more importantly: Is there a benefit to executing project startup without the full compliment of technologists that we'll need for full-steam-ahead solution development?

The answer to this is usually a resounding "Yes", there is a benefit. A good bit of the reasoning and guidance is found more in the Lean Startup and Lean Product Development bodies of knowledge than the colloquial Agile body of knowledge.

There's a time to activate a full compliment of development staff, but the optimal time is rarely the start of development work.

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

The Least Way: Pivoting Away from Agile Excess

2010-10-20T16:00:00.000-05:00

One of the most compelling justifications for Agile development methods and techniques is made through a comparison of the cost curves of both Agile and "traditional", or "non-Agile" methods.

When Agile was new and its case was pleaded more frequently, the following graphic was quite common:

NOTE: The above graphic is intended to represent to relative shape of the cost curves, and not convey exact scales for your organization. Your own organization's cost curve mileage may vary.

The Cost of Traditional Development

The essential proposition is that the cost of a unit of software development effort gets exponentially higher as a project progresses. The same curve represents the cost of change of existing features equally as well as the cost of adding new features.

The underlying principle is pretty straight-forward: the more stuff you have, the more stuff that will go wrong that you can't predict and that you don't detect. The more stuff going wrong, the more rework in-progress. Rework is the crumbly raw material that makes all foundations shaky - be they the foundations of software, or the foundations of the plan.

The number of modules in a software project increases as a project progresses. The number of inter-relationships between modules grows as the number of modules grows. The number of unpredictable repercussions of any change to existing modules or addition of new modules, as well as the extent that repercussions dissipate throughout a system of modules, increases as the number of inter-relationships increases.

When there are fewer modules, it's much more straight-forward to add new modules. However, at a critical turning point, this ease rapidly erodes and it becomes exponentially more difficult to get work done without undoing work that was done previously.

The more modules in a system, the more likely that any new additions or changes will cause adjacent modules to no longer work as they once had, and to no longer work correctly. The longer that they stay in this incorrect state, the more that other adjacent modules will be built incorrectly, or built in a way that reduces development productivity.

The more modules that are in a system, the less likely it is that its programmers can assess any detrimental effects brought about by changes. The system becomes an increasingly unsolvable puzzle that must be solved every time a change is made to add new code or to change existing code. Early on in the life of a system, the puzzle is dead-simple to solve. As the number of modules grow, the possibility of solving that puzzle with every new change closes in on improbable. This is the source of the extra effort that accretes around software development as time goes on.

How Agile Flattens the Traditional Costs

The Agile cost curve is fundamentally different. It was such a radical re-imagining of managing the factors that influence the cost curve that it was frequently dismissed out-of-hand, despite affirmations and reports from people who had given it an honest empirical and experiential trial.

Agile development's power rests in the drive to recognize the conditions that cause the cost of effort to increase over time. It uses techniques that keep effort leveled over the length of a software project, rather than allowing them to spiral toward the inconceivable, unpredictable, and unmanageable.

The cost of change is controllable only when you can predict whether any change will have detrimental consequences. You need to be able to apply countermeasures immediately when any of these detriments are created. The longer the wait to detect a design flaw, the faster the cost grows. This ultimately leads to the vicious circle of rework, where problems are found after the work is delivered to the next phase in the development process, while developers continue to build on that work, believing it to be a sound foundation.

In other words, Agile's radical re-shaping of the traditional cost curve comes from the ability for workers to easily and continuously check that their work isn't a cost magnet while that work is still open on their workbenches. They embrace a principled understanding of the kinds of software designs that are directly and easily tested, and a diligence paid to recognizing, avoiding, and remediating designs that aren't.

And of utmost and paramount concern - concern that can make or break an Agile effort: that organizations realize that its the rigidity of organizations and organizational systems and behaviors that obstruct software development from being done in a way that allows software workers and teams to rehabilitate the traditional cost curve. The impact to organizations - especially entitlements to silos and rigidity - can be profound. Organizations adopting Agile have a responsibility to shift from defensible, garrisoned blame cultures to proactive, optimized learning cultures. If the organizational and management system locks the steering wheel into one, largely immovable position, there should be little surprise when projects end up in the productivity ditch.

The Agile cost curve also suggests that there's a bit of a startup tax to pay up front, but that once the initial bump is navigated, productivity stabilizes and becomes much more predictable.

This is in contrast to traditional methods where the inherent absence of complications early-on lulls developers and managers into a false sense of success. They fail to practice productive countermeasures from the very start by failing to recognize the technical and organizational naivete inherent in the work. The success doesn't last. It's outlived by the realities of the exponentially-increasing number of complications that are natural side-effects of the progress of a software development effort.

The Agile Project Startup Tax

The graphic depicting the Agile cost curve overlaid on the traditional cost curve tells this whole story at a glance. This is what makes it so compelling. And yet, while the Agile cost curve is incredibly compelling, the most interesting point of the graphic isn't so much the benefits that Agile methods avail, but the point on the curve where the lines intersect:

Before that point, Agile development has a higher cost. Before that point, traditional methods should have a lower cost. The time spent using by-the-book, colloquial Agile development techniques before the point where traditional techniques become too costly is a likley volunteer mission for exacerbated costs.

The Best (or Least) of Both

A methodology that uses aspects of traditional development up to the point the costs of traditional methods are on the verge of spiraling out of control, and then makes a methodological "pivot" to techniques that can be considered "Agile" can reap the benefits of each approach's strengths.

Such a "blended" approach takes advantage of traditional methods that, while unsustainable, can deliver more bang for the buck up-front. The resulting path has the least amount of cost if the pivot is well-executed.

The resulting methodology is both traditional and Agile based on where work is in the project timeline and in the smaller development cycles. Neither its traditional aspects nor its Agile aspects are left unchanged by the imperatives of blending what is usually seen as incompatible methods into a continuum. But the most effective and salient principles of development productivity remain in-play.

My own practice of that continuum is informed by Lean Development, and more recently by the Lean Startup movement and its understanding of up-front phases that are often not mentioned by predominating methods like Scrum, and traditional methods that came before.

The Least Way

I was bemoaning failures with Agile and Agile community to Jason Cohen a couple of years ago. He offered the "The Least Way" as a name for the approach that I was embracing to deal with a number of the issues with Agile stasis and orthodoxy that I was trying to work around. I'll ultimately add more meat to those bones on LeastWay.org, and talk about how it underlies some tooling that I'm working on, and how it has affected work on projects. Maybe you'll find it as useful as I have if packaged up in a consumable form.

One of the key differences between an approach that doesn't just cherry pick techniques from different methodologies, but executes a full methodological pivot, is the explicit management of that switch. Planning for it, preparing for it, recognizing the right time to make the pivot, and making a clean entrance and exit from it is a bonafide part of the practice.

Missing the pivot is like missing the last exit before entering the Lake Pontchartrain Causeway. By the time you've realized that you've zoomed past your best chance to take the turn off, you've likely been captured by the gravity well that will start you toward the acceleration of costs. The cost curve begins it's rapid incline immediately after the pivot. The longer it takes to realize that you've missed the turnoff, the faster you'll be traveling, and the more you'll have to spend to put on the breaks and get back on-track toward managing the cost-per-effort.

Shaping the whole methodology around the pivot changes some of the conditions that drive staffing and work management at different phases of a whole software effort. It's not just "changing gears", but more like changing vehicles while they are still moving: you'd want to have vehicles designed for this specific purpose. Modifying the existing vehicles is a good place to start.

With the pivot being a full-fledged part of the methodology, with practices in place to recognize its approach and to execute it cleanly, the cost curve should be smoother, representing the best of what traditional methods have to offer - up to the point that they become unsustainable, and the best of what Agile has to offer - but not before it is sensible.

It's easy to see the methodologies as "one vs. the other" issues - "traditional vs. agile", for example. This perspective can even be helpful when more radical approaches are needed to shake up a rigid, entrenched, silo culture. However, plotting methodologies along a continuum helps us to see those parts of the spectrum where one blends into the other, and to learn to recognize and take advantage of the distinct transitional phases between them that we might otherwise miss or ignore.

Our tendency to look at some colors as "primary" and those in-between as "secondary" is largely an arbitrary side-effect of perceptual bias. The spectrum is one, fluid continuum of material that is neither primary nor secondary. When we choose to see transitional states as secondary, we naturally tend to tune them out. The powerful continuum of abilities that flow smoothly from each other is turned into a checkerboard of disconnected, shallow monotones.

Rapid feedback is the lifeblood of software development that doesn't spiral out of control. Agile protects vital feedback mechanisms from becoming calcified after a projects initial phases. Traditional methods provide rapid - but unsustainable - access to product and customer feedback early-on. Leveraging both and planning for and executing the transition as a fully-fledged part of the methodology rather than a secondary interest is a good part of navigating a "least way" of development obstructions (and costs).

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

User Stories Belong to Everyone

2010-10-04T08:55:00.001-05:00

When Agile development is done well, user stories are always visible to everyone involved in turning ideas into working products. And they're visible all the time. When individuals or individual specializations involved presume a sense of "ownership" over user stories, doing Agile development well becomes difficult if not entirely impossible, save for a veneer of "Agile Theater".

As user stories flow through the whole development process from conception to delivery, they pass through the hands of a number of job functions and workers. Any time that people working in the vicinity of a given work step are given to believe that they "own" the user story in their current purview, they are likely to displace the user story from the most public and most visible medium that is common to the whole team. User stories are often then removed to the bowels of tools that are practical and accessible only to workers at the current work step and its immediate vicinity.

User stories can, do, and should change as they march forward through elaboration from concept to working product. Product development is a process of constantly unearthing a clearer understanding of the work we're doing while we're doing it. No amount of up-front analysis and design can stop this from happening. It's the nature of the kind of work that software development is, ie: product development.

If software development were manufacturing work, we'd know what would be happening in each step of the process before it happened. But then, we'd have to be creating exactly the same product again and again, which would be nothing short of an absurdity for software development.

The further we get into the process of turning an idea into concrete, material product, the greater the clarity and amount of thinking that gets invested into what we're doing. The more thinking invested, the more that we come to understand the subject matter we're working with, the circumstances of product's intended audience, and the fit of the decisions we've made earlier in the process to the reality waiting at the end of the process when real workers will try to do real work with the delivered product.

Analysis and design are present in absolutely every kind of work done in software development, and present in every stage and every work step. And while we may indeed have work steps early in software development processes that appear to be characterized by work exclusively in analysis and design, this is ultimately a consequence of not having concrete product yet in-hand at those early stages.

These early stages are less "Analysis and Design" stages as they are "Absence of Material Product" stages. We resort to seeing early stages as "Analysis and Design" due more to a habit of human perception that tends to draw attention to things that are present than to things that are absent. But later stages are no less "Analysis and Design" stages as a "Testing" stage in any less of a "Development" stage.

It's the same cognitive wrinkle that makes negative space visualizations like Rubin's Vase or the FedEx logo so compelling when we finally recognize the secondary images conveyed by the space that our cognitive facilities filter out. It's also what keeps us from being in a constant state of anxiety due to cognitive overload, and what allows us to be mindful of predators (not to mention to be unmindful of camouflage).

The kinds of work we do in software product development are rarely unique to any given stage. The kinds of work we do accumulates continuously so that later stages have responsibilities for nearly all of the kinds of work done in software development throughout the entire process. That's not to say that front-loading software development work with conceptual work is a bad idea. It's obviously an essential part of doing product development work successfully. But it's easy to mistake early-stage work as the domain of "analysis and design" due to the absence of material product this early in the game. The absence of material product at early stages should be a conspicuous absence, but the conspicuousness is typically lost to cognitive filters.

The disastrous side effect of failing to recognize this negative space perspective is the mistaken conclusion that analysis and design is the sole domain of early-stage work. And it starts the people involved in software work on the slippery slope toward believing that work on requirements analysis only happens early in the process, and that requirements - once defined - will not have to change. As if we could really know anything so conclusive so early in the process of uncovering clarity and understanding.

In the end, early stage work is naturally limited in that it can usually only be conceptual work. Conceptual work is realistically the only work that can be done so early. While the accumulation of responsibilities at work steps later in the process continues, analysis and design never wane. New clarity and new understanding never subsides. In fact, clarity and understanding only get sharper. This continues even once a software product has been made operational.

Because understanding continues to get sharper the further along we are, any concrete record of our understanding must be kept up-to-date to make sure that our collective clarity remains collective. Otherwise, workers at different stages of the whole process will have different understandings of what the goal is - as currently defined by all recent learning.

Making sure that everyone is on the same page is of paramount importance in any development effort. Locking down the definition of what's needed isn't the way to do this - although it's often the mistaken path that software organizations take when they fail to recognize the cumulative nature of understanding and clarity as product development unfolds.

To keep everyone on the same page, user stories must be accessible to everyone involved in a development effort, from early-stage conceptual work, all the way through delivery when placeholders like user stories are replaced with concrete, material product. They must be accessible with the least amount of effort by all people involved and at all stages and work steps.

At any point in the whole process, anyone who is empowered to add user stories, change existing ones, remove user stories, or otherwise make use of them should not have to go through a worker with specialized tool skills due to user stories having been removed to a tool that is not generally-accessible with an absolute minimum of effort and a maximum of immediacy.

Stated as a general principle: No single work group at any work step should remove user stories to a medium that, while more expedient to their work, causes user stories to become less accessible by others with different skills and responsibilities.

The inevitable result of workers at a work step feeling that user stories can be removed to a more locally-optimized medium is that separate copies of a user story will be used by workers at different work steps, and these copies will inevitably diverge. When multiple copies of the same user story diverge, workers at different work steps have different understandings of expectations and goals, and work at cross purposes.

In the worst of these situations, workers at different work steps aren't even aware of the others' divergent versions of the truth, and labor under the resulting conflict without any idea as to why expectations are consistently not being met. This drives up rework, reduces the credibility of the team, increases stress and conflict on the team, and generally leads back to the chaos that Agile development was supposed to address.

And yet, there are indeed advantages to specialized tools for specialized work steps. Great care should be taken though when considering specialized tools for artifacts that aren't specialized. It's often a mistake and an oversight when specialized tools are put in place at a work step that makes collective artifacts less accessible for the duration of the work step, or from that work step onward. In the case of user stories, it's hard to find a single artifact that is more collective, public property and thus less amenable to workstep-specialized tools.

At every stage of development, workers can back-slide into misconceptions of authority over artifacts that are responsible for unifying the whole effort and for stitching diverse workflows and workers together. The further we get into a software process, the more likely it is that workers at a later stage will remove user stories from more generally-accessible media and sequester them into the bowels of tools that are accessible only to people with specialized skills.

For example, consider the Cucumber framework and tools developed in the Ruby community, and the family of derivatives and clones that have since been created in a host of programming languages.

This style of tool encourages the displacement of user stories from more generally-accessible media into programmer-specific media. It doesn't do so accidentally. It's done as a recommended practice - reinforced by articles, books, and software conference presentations and workshops.

While Cucumber is built on some fairly compelling technology, and is itself an impressive work, it's not exactly methodologically-sound in that it fails to recognize its own contradiction of Agile development's core value of individuals and interactions over processes and tools.

As an aside, I brought up this issue with Aslak Hellesøy, the Principal of the Cucumber project, during a trip to Sweden last year. At the time, he informed me that work was being done on a tool to extract user stories from the specialized media to make them generally-accessible. But there are three non-trivial oversights inherent with this solution:

Firstly, it disregards the a-priory value of whole-team organizational methodologies like Agile by allowing collective and communal artifacts that are fundamental to higher-order productivity to become appropriated by one specialization.

Secondly, it seeks to address a problem that exists because of overly-elaborate tooling by creating even more elaborate tooling. The path back to simplicity and clarity - i.e.: "elegance" - likely also suggests removing the first wave of tooling rather than adding a second wave of compensating tooling. There are presently solutions that are arguably more holistically-effective as well as arguably more simple and clear. Although, they're based on less elaborate programming technology, and this is likely why the programming specialization remains distracted for alternatives.

Thirdly, it doesn't address the need to allow user stories to be added, removed, combined, divided, or changed by anyone with the authority to do so regardless of whether he or she is comfortable with tools, approaches, and perspectives that are more natural to the programmer specialization.

A Cucumber-style tool can be justified arguably as a general tool because it serves the whole of the process with testing and specification, but merely serving the whole of the process doesn't atone for the reduction in accessibility and immediacy of collective artifacts.

To Aslak's credit, he demonstrated a way of using Cucumber to me where user stories are not removed to its media. Nonetheless, removing user stories to Cucumber media continues to be a practice that is perpetuated in the user community remains a non-trivial methodological problem that is likely rooted in the narrowing of focus of specialized workers due to impressive tooling.

NOTE: There are more methodological oversights inherent in these tools, but that's a subject for a subsequent article.

Here a some principles to keep in the forefront of your Agile practice amidst the distraction of so many Agile-targeted tools:

1. Individuals and interactions over processes and tools has profound meaning. It doesn't suggest that you shouldn't use tools or processes, but that these often become distractions from more powerful means of ensuring success. Consider tooling choices very carefully - especially specialized tooling. Understand how it might inadvertently narrow the perspectives and values of its users.

2. User stories are a whole team artifact. Any tool that moves user stories to a medium that the whole team doesn't have at their finger tips should only be used when there are no viable alternatives. Forcing some team members to go through other team members to work with collective artifacts is categorically not what is intended by individuals and interactions over processes and tools - even if it does cause people to work together to gain access to resources. These resources are supposed to be generally and immediately accessible to begin with.

3. If you choose to remove collective artifacts to workstep-specific tools, put protocols in-place to ensure discrete hand-offs between tools so that multiple versions of the truth are not available to different workers who work in different work steps. When a user story moves from one system to another, destroy the previous version and leave behind a placeholder - a kind of forwarding address for a user story - that tells the interested party how to find the user story's new home.

4. Don't fool yourself into believing that you'll be able to keep multiple versions of user stories in-sync through the life of a project. This kind of work is too costly to keep up and will be quickly abandoned by the project team, leading straight back to the multiple versions of the truth problems. Adding customized electronic synchronization automation to this problem is also not a good answer. This just adds more elaborateness to a situation that is possibly already too inelegant. It's a problem that likely shouldn't exist in the first place.

The inescapable truth of user story management is that the least-elaborate technology is often the most productive solution - even if the technology is no more elaborate than a ten-foot by five-foot cork board with index cards pinned to it. In the very least, this keeps user stories immediately visible and accessible, and makes changing them no more difficult than putting pen to paper.

Of course, the tried and true cork board and index card solution isn't a good foot for all teams. That said, as you seek more elaborate solutions, take tiny steps forward in settling on your solution. A leaping at the most elaborate solution for user story management usually ends up planting a whole team in a tool that serves the specialized perspective of the people doing the tool selection - often to the disservice of everyone else involved in the whole effort.

It's vital that we're not lured into local optima interpretations like, "individuals and interactions over tools and processes except when the tools are intellectually stimulating". All tools are intellectually stimulating. In many cases, tools can be stimulating to distraction. The problem is what we're being distracted from: the essential root cause of success in software product development. Namely, the magnification of understanding and clarity that comes from interactions between individuals over the course of time. The deeper problem is that we believe ourselves to be impervious to this kind of distraction because we have such positive feelings about our tool choices.

The immediacy and accessibility of user stories is a foundational corner stone that your Agile house is built on. Whether it stands strong and continues to be built upon, or whether it crumbles under its own weight can be decided entirely by this salient factor.

Do everything you can to make sure that user stories continue to belong to everyone, in every minute of every day. And be vigilant against any backsliding into specialized expediencies that remove user stories to any medium that is less immediate or less accessible than the simplest and clearest of tools at our disposal. An elegant solution is often not an elaborate one, but greater whole-team productivity is always more stimulating than elaborate, specialized tools.

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

User Stories are Temporary

2010-09-28T09:55:00.003-05:00

It's obvious, but warrants mention: What we do in the future is likely to be different from what we're doing today. The implications for user stories should be obvious: User stories are temporary. Saving them for posterity doesn't serve the primary purpose of user stories, and doing anything that makes them less temporary can turn user stories from benefit to detriment.

User stories are a bit of semi-refined raw material that systems are created from. They're a way to represent users' needs. Most importantly, they communicate an understanding of users' context to the people who are building the software. User stories help to make it more difficult for software development teams to succumb to the ever-present threat of losing track of the user's bigger picture.

Aside from raw human ideas that user stories represent, they are the most flexible artifact in software development. Then can be created at any time. They can be changed at will. They can be combined. They can be subdivided. They're not intended to become fixed, and anything that serves to make them fixed is a disservice to the value they offer. User stories aren't fixed in a point in time, just as needs aren't fixed. They change because conditions change. They change because our own understandings change and improve as we gain the clarity that comes from working with user stories, and from building the products that satisfy needs.

When we realize new clarity, our responsibility is to reflect that new clarity in the form of new stories, or new subdivisions of existing user stories, or through the combination of existing user stories, and even from the removal of user stories from the product definition entirely.

The user stories that describe our needs tomorrow are going to be different from today's. Knowing this as we do, we have we gone from recognizing the transient, temporary nature of user stories to the point where we now tend to capture them in tools that make them harder and to change, and harder to take in at a glance and to glean new clarity from. When we do this, we're increasingly unlikely to update user stories to reflect the improved understand we cultivate as we work with them, with users, and with the software that we're developing.

The more that we calcify user stories in ever more concrete media, the less we make necessary course corrections along the way. There is little that so obviously contradicts "Agile" more than inviting anything that adds to the calcification of requirements. A principle duty of user story management in Agile development is to protect them from becoming encumbered by the notions of permanence that obstructed software development methodologies that predate the effectiveness of Agile methods.

We pat ourselves on the back for having evolved beyond the quintessentially-primitive "300-page requirements document", but often all we're doing is bringing some of the same old problems forward to our "new" requirements formats. Sure, we've outgrown the massive, big-batch requirements doc, but the genetic material of the disease that infected those documents have evolved into a newer problem for newer artifacts, and ultimately, the problem is still the same essential problem. We're so pleased with ourselves for our new Agile ways that we fail to see that we're repeating the same mistakes, except with new material.

Here are some things to keep in mind that can help with the relapse into the same old mistakes:

1. When you forget why you're doing something the way you do, the answer isn't in a user story archive. The answer is in revisiting what you're doing to make sure that it still holds true. Do this with interactions and with people. Use tools and processes to support the human interactions.

2. User stories are not artifacts for regulatory compliance. User stories are a scratch pad of human understanding at the present moment. They are chuck for the software development grinder. What comes out the other end should be the software that itself explains why things are as they are. If you need a permanent record for the purposes of regulatory compliance, go ahead and create one. Nothing in Agile stops you from doing that. Just don't hang a stasis anchor around the neck of user stories. If you do, you'll strip them of the benefit that they bring to software delivery.

3. Have one master copy of a user story while that user story is in-progress. The master copy should be the one that is most immediately accessible to the most people who are involved in turning ideas into software products. They should be be posted using the most visible medium possible - one that requires the least amount of human interaction to casually-scan a project's gallery of user stories.

4. Throw user stories away once you deliver the working software that addresses the needs expressed by user stories. The software and its supports are enough to describe why it is the way it is. If you no longer remember, and if the software and its supports and the mechanisms and practices of institutional memory aren't sufficiently self-descriptive, revisit all of these issues as an opportunity to improve the production system in a way that doesn't invite more tool-centric bureaucracy.

Here's a bit of a side note to consider: The principle sponsors of the Agile 2010 conference are both "Agile" tool vendors.

If one of Agile development's primary tenants is to value people and interactions over processes and tools, how is it that the only Agile organizations producing enough disposable income to support Agile development itself are tool and process companies specializing in Agile requirements management and requirements compliance? Somehow, we've walked in a circle - yet again. And one of the things we've left on the trail behind us is the understanding of how things went wrong last time, as well as our commitment to avoid expediencies that don't serve sustainability.

The process methodologies that predate Agile are often roundly dismissed by agilists. But there wasn't really inherently wrong with them. Things back then started getting silly when tools started getting silly; when we began to defer to tools as authorities rather than to the people needing and the people solving needs.

One of the first definitive steps into the downward spiral of mindless process bureaucracy hell is the calcification of requirements. And no matter how temping it is to succumb to the materialism of hardened collections of user stories, we don't get to hell without passing through those gates.

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

Workplace Safety for Software Developers

2010-09-13T10:00:00.010-05:00

Software development managers make sure that their workers' physical safety is secured - assuring that office ergonomics are up-to-spec, and in compliance with the prevailing laws and regulations. On the other hand, managers verily require that software development workers undertake some of the riskiest behavior in the contemporary workplace. It's entirely common that software managers require workers to undertake work the crosses the line of being merely questionable, and moves squarely into the territory of negligence. It's not because software development managers are nefarious, but because they are too-often far enough removed from the work of software development to differentiate negligent and hazardous decisions from safe and sound decisions.

Without a tangible understanding of the work undertaken by software workers on a day-to-day basis, and an understanding of that work in great detail, software managers are not equipped to know when they are requiring software workers to supplant safety with expediency.

Workplace safety is an issue of productivity. Lack of safety breeds low productivity. In the case of software development, "safety" is an issue of undertaking work in a fashion that doesn't expose the software worker to unnecessary risk - especially risk that is easily avoided. That is, it's easily avoided for someone who understands the work of software development at a high-enough level of expertise and detail to guide workers away from unsafe practices.

An unsafe practice in software development is any work done in the present moment that makes work in the next moment take longer to complete. A reasonable analogy for this is the notion in physical materials work of a clean workplace.

The purpose of a clean workplace is to remove the clutter that hides unseen, unsafe conditions. It's a lot easier to trip over an errant piece of material in the workplace when its surrounded by a profusion of other errant materials. When hazards are so common that they blend into the background, we simply stop noticing them, and this is how we come to be put at greater risk.

The more unsafe clutter we have in our workplace, the more we have to work around. The more we have to work around, the more time it takes us to do work.

If a manager can't detect the conditions that makes work take longer to accomplish than expected, he doesn't adjust his expectations for cycle time accordingly. This means that he expects more to get done - the original work, plus the workaround work - in an amount of time that would be reasonable for the completion of the original work alone.

This makes workers even more careless, exacerbating the accumulation of obstructions and hazards in the software development workplace as a result. It's a vicious cycle that usually only happens because someone with the authority to avoid problems in the first place doesn't have the experience to recognize the problems and to deal with them.

In the words of the ancient Chinese workflow master, Lao Tzu: "Confront the difficult while it is still easy. Accomplish the great task by a series of small acts."

Although, you can only do those small tasks if you can detect their presence. The finer your ability to perceive counter-productive deviations, the quicker you can respond to them. The longer you wait, the further off-course you'll be when you finally realize that you need to make a course correction. Someone who doesn't do work can't recognize when that work is off-course. Someone who isn't an expert in the work can recognize when the work is off-course, but his will only recognize it after it has become more expensive to deal with than necessary.

And this, as the average software worker would tell you, is the day-to-day conditions in which their work is done. Software work is a constant battle fought against the accumulation of hazardous clutter. Software workers rarely get ahead of the clutter curve, and have to invest significant effort to keep their workplace free of hazards. Paraphrasing Taiichi Ohno, if you're not moving forward, you're falling behind.

Each individual scrap of hazardous material in software development is typically quite small - small enough in fact to be easily deemed negligible - even by people who do the work. The hazard presented by two iota of hazardous waste in software isn't the sum of the hazards - it's the sum of the hazards compounded by some multiplier. Hazards in software don't exist in isolation, they interact with each other creating a higher order of hazards that is greater than the sum of their parts. Two pieces of hazardous software that interact with each other don't create two hazards, they create two hazards compounded by the amount of interactions between these modules. To make matters worse, all modules that interact with hazardous modules in close adjacency also get infected. Lack of day-to-day expertise in software work often leads to negligent underestimation of the risks associated with the "design hernias".

Software hazards compound very quickly. It's very easy to arrive at an explosive accumulation of hazardous software materials. It can happen within the first few days of a software project. If subtle hazards in the tools and frameworks that programmers are slated to use are not recognized immediately, the accumulation begins before the first line of code is even written.

When we ask software workers to continue to work in such conditions, we might as well send them into a mine filled with coal dust and require them to hyperventilate for several hours each day. Sooner or later they are going to have to escape the job to escape the hazards, or they are going to acquiesce to the irreconcilable differences between a manager's expectations and the realities of the working conditions that the manager himself feels entitled to not be exposed to for having already "paid his dues". This creates dispassionate cynicism in software developers. They come to learn that no matter what they do until they escape the work, they are more than likely going to end up on the losing end of the software work proposition. They learn that they'll get hung with the detritus of negligent software development decisions and direction because decision makers are too far removed from the work to see that it is these critical decisions and directions (or the lack thereof) that are the root cause.

In these working conditions, workers constantly face obstructions that are only in-place because they weren't recognized when they were mere seeds of problems rather than towering oaks of looming counter-productivity.

The accretions of hazards into founts of the depressed productivity that is status quo for most software teams is fully and completely avoidable - if only the hazards are dealt with when they are small. To see looming hazards when they're small, you have to have detailed knowledge of the work in the here and now. This is simply not possible when managers have removed themselves from the work.

It's far too common for software development managers to feel entitled to be removed from the work of software development - as if removal from the work is a reward for having done the work for a number of years. The reward for doing software development work for a number of years is not an escape from the work, but an immersion into a far deeper understanding of it so that its expert insight can guide software work away from hazards. Of all the escapes that can be orchestrated by software workers, an escape into management is indeed and in fact an act of pure negligence.

Software work is works in intangibles. Software hazards go unnoticed because they are physically invisible. Taking a bit of liberty with Donald Reinertsen in The Principles of Product Development Flow, we don't see the manifestation of software development safety issues "when we walk through the engineering department." They're "bits on a hard drive, and we have very big hard drives in product development."

Managers often try to compensate for their lack of detailed understanding through the use of summary representations like software diagrams. But software diagrams don't show the looming problems while they are still small; still manageable gathering storms that can be dissipated through judicious application of minimally-invasive countermeasures. Only flagrant hazards can be detected in summary representations. Small, detailed course corrections can't be plotted from coarse, summary information. And yet managers who feel entitled to be removed from the work perpetuate the fantasy that summary representations like diagrams are sufficient to bring their purview into action on the software projects they manage. This is pure folly, and software tool vendors are quite happy to continue to exploit it.

By the time you've detected a software hazard that can be seen in a summary representation like a software diagram, you're looking at a problem that has festered for far too long. You should be able to detect the chemical markers of the disease long before you notice that lump in a vital organ.

Programming work is almost entirely mental. Its effectiveness is influenced by psychology, cognition, awareness, and communication far more than by any material concern like ergonomics, an ultra-fast workstation, or multiple monitors. Software systems are far too large and far too complex to be held in entirety in the conscious focus of any single software worker in any single moment. The devil is always in the details. Summary representations are secondary to the actual raw materials of software: the code. You have to be in the code, and to know enough about code to understand which subtle design differences are looming problems and which aren't.

The average software system is a dark coal mine filled with the poison particulate of tomorrow's case of black lung. We ask developers to work in these conditions every day. We do this because at some point in our careers as managers, we believed that we were entitled to be removed from the details of software work.

Sooner or later, enough hazardous software material accretes in a software system that managers step in, and often the first thing they do is look for a root cause in the workmanship of the software workers. The workmanship is rarely the root cause. The absence of informed, skilled, and insightful software management and guidance is always a preeminent cause to unattended workmanship. The workmanship is, of course, a problem, but it's a side-effect.

This is like blaming miners for an underground explosion due to the accumulation of day-to-day hazards that result from institutionalized negligence of clear and present dangers that should be managed the moment that they show their first signs. We ask workers to undertake work that they know is not in their best interest. We ask them to do this from our organizational perches far about the hazardous conditions of software projects. And then we hang them with the inevitable costs of this kind of mismanagement.

It's the software worker that is required to spend extra time in the mine to balance productivity that is lost to management negligence. It's the software worker who is required to take on the duties on sanitizing data by hand without the safety of the proven automation that should have been built right to begin with. We ask them to validate the decisions that we've made about the tools that they'll use in their work based on little more than a compelling sales pitch from a tool vendor who claims to knows more about the day-to-day work of the software developers in our organizations than we do - vendors who are even further removed from the work than we are.

We ask software developers to work against their own interests and the interest of our organizations because we don't understand the hazards that our decisions create.

Software workers suffer disruptions to their lives and their livelihoods when this kind of institutionalized negligence drives work policy on software projects. They shoulder the accumulated detritus of uninformed and unskilled management decisions. And they suffer the humiliation of blame when lack of management insight can't see it's own reflection in the root cause mirror. And institutions lose the invaluable institutional knowledge when workers escape the organization altogether. It's always a no-win situation. Everyone loses. And it's completely avoidable.

If you're not willing to be in the day-to-day work of software development, you're declaring loud and clear that you're not qualifying yourself for the authority to make decisions that direct software work. Every decision you make risks adding to the accumulation of software hazards. When you do this, you deplete the workplace safety for software workers. You ask them to take risks that the workers themselves know that you can't see, and they know that because you can't see them, that you will likely not understand that the accumulation of avoidable hazards into full-fledged, clear and present dangers is your fault to begin with.

Workplace safety is a serious productivity issue. It's a serious issue for the health of workers. It's a basic expression of human respect for the people who work for software development organizations. Understanding workplace safety for software developers requires a high level of expertise in software development, and it requires day-to-day currency in software development. A manager who is not willing to have insight into the details of the work that he is responsible for is patently disrespectful of his workers. He constantly puts them into harm's way by presuming to express authority without knowing whether his expectations are hazardous to the health, well-being, and viability of software work and software workers. Beyond disrespectful, it's dishonorable.

The software field isn't at risk of programmers forming a united front and leveraging collective bargaining, and frankly such a thing isn't likely what anyone wants. But dealing with the root cause issues that have driven other industries to such actions is a win for everyone when obstructions to productivity are removed in the process. Addressing software development workplace safety is a good place to start - especially in our current economic conditions, where a massive boost of unimaginable untapped productivity would be a welcome change indeed.

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

The Unfortunate Case of Agile Coaching and Servant Leadership

2010-09-10T08:40:00.041-05:00

The need for coaches, and especially servant leaders, is a side-effect of an unfortunate organizational pathology.

Consider this quote from James P. Womack: "We've got too little management and therefore need too much leadership".

Someone who has become specialized as an Agile coach necessarily benefits from the perpetuation of Agile coaching. This doesn't mean that Agile coaches are nefarious and interested in suboptimal outcomes, but perpetuated specialization typically creates narrowed perspectives and thus overly-narrow interpretations of conditions and needs.

The result is often the very same counter-productivity that we observe when someone is given the exclusive job of capturing requirements for a software project: they fill all of their time exercising their specialization, creating an inventory of work that is out of sync with the progress of the team.

When we bring Agile coaches into software development efforts, we should recognize the underlying problem that is being signaled: that software development managers are not presently equipped to manage the software development work that they've been tasked to manage.

By failing to recognize the underlying problem, we often go too lightly into engagements with Agile coaches, and we end up failing to use them to solve the root cause problem, and this perpetuates the need for longer engagements with Agile coaches. This, in turn, drives Agile coaches further into the reaches of specialization, and narrower perspectives, accelerating the erosion of their usefulness.

To break this cycle, we need to recognize the most important reason to bring on an Agile coach: The purpose of an Agile coach is to transform managers and the management system so that managers, in turn, can transform their organizations.

Coaches initially take on responsibilities that ultimately need to be the responsibilities of a manager. Even if the outcome is an improvement, when a manager's job is split between an authority position (the Boss), and a guidance position (the Coach), the outcome isn't as good as it can and should be. Nonetheless, if a manager is in a position to need a coach, then the coach is inevitably going to take on some of the manager's responsibilities for teaching and transformation while the manager undergoes rehabilitation of his own.

The coach and the manager must recognize that these conditions are a necessary evil. The goal is a transition away from the split direction of a team between a manager and a coach. The longer that this split is in place, the higher the likelihood that the new behaviors learned by the team will be undone by the manager when the coach moves on.

Agile coaches can find themselves as removed from the work of software development as the managers that they are called to rehabilitate in the work. For an Agile software development coach to remain effective, he has to be an active software developer. Just as managers fall into the trap of losing software development currency, so do Agile coaches. An Agile coach who doesn't also do software product development for a living is a ticking timebomb of counter-productive guidance for a software development team.

Consider this quote from Daniel Markham: "If you're going to train something, you should be able to do it. And I mean do it to a very high level of expertise. An agile coach should be able to code, perform analysis, manage the project, test -- anything that needs doing on a project. If she can't, then how can you talk to her about your particular situation? If your agile trainer was a BA last week, or never slung code in his life, or is a professional trainer, or -- let's be brutally honest -- is making less than the members of the team are, you've got a dud. It seems like common sense but it bears repeating: you can't train something you haven't done. And "done" means a bunch of times, not just on the pilot project."

The qualities and abilities that Daniel outlines are qualities and abilities that we need to expect from software development managers. If they don't have those qualities and abilities, they need to get them, and a coach might be a way to get there. If the coach doesn't have those qualities and abilities, most of what's produced during the engagement doesn't become lasting, transformative value.

Agile coaches who themselves don't know the work of software development can't teach managers to know the work sufficiently to manage it. They can only teach them to become other disconnected Agile coaches. This is how the second half of the first decade of Agile came to be dominated by the doctrine of Servant Leadership. As more senior leaders in the Agile community spend more and more time in roles that are ever distant from the work of software development, Agile itself is becoming more robotic, more mindless, more of an orthodoxy, and even more of a liability than a benefit.

Servant leadership is one approach - one tool - fit for the organizational conditions that it serves best. An Agile coach often embraces the edicts of servant leadership as a universal panacea when his duty to stay sharp in the full curriculum of software development is dulled by the ease of Agile coaching specialization. But any tool used indiscriminately is going to undo any benefits that it provided in the circumstances where it was an appropriate choice.

A servant leader's typical proposition is that an organization's ability to meet expectations will be transformed if only its inherent creativity can be tapped and unleashed. While tapping and unleashing unused creativity is transformative, it's extremely rare that doing so is either sufficient or sustainable. It often creates conditions that not only lead to unmethodical exploration of ideas, but also makes teams feel that they have a right to this kind of behavior. In other words: "self-determination" rather than "self-organization".

Servant Leadership as a panacea is also a real side-effect of past experiences with bully management. It's an over-compensation reaction to some very real and very tangible painful experiences of abusive directed authority. It's an equal and opposite reaction to an extreme. It, as well, is an extreme. It's as much an undesirable specialization of behavior as abusive directed authority. It's often a programmed predisposition, rather than a conscious choice informed by circumstance.

The Servant Leadership doctrine often patently dismisses the greater goal of balance between directed authority and creative enablement, almost entirely eschewing the value of informed directed authority and skilled directed authority in favor of an over-indulged creative enablement.

A job in creative enablement is a lot of fun, and many Agile coaches have come to feel entitled to these kinds of engagements. They're light, they're fluffy, they can come with no measurable expectations, and they're often damned lucrative - especially in software organizations in the thick of the detritus of an unrecognized management crisis.

The increasing prevalence of Servant Leadership also presents a great opportunity for consultants with little real experience in Agile to re-brand themselves as Agile consultants. It allows for anyone with even a modicum of summary knowledge of Agile development to have a role in the Agile bonanza. But we all lose when this happens.

If you don't already know what your problem is, then pre-supposing an Agile(tm) solution further deepens the mindlessness of robotic management, and it diminishes the Agile body of knowledge. And ultimately, it exposes our organizations to the risks of bringing in help that may only have the ability to talk the talk - which is often all that is required of Servant Leadership - and often all that servant leaders assert is required of them.

Again from Daniel Markham: "One guy (famous author again) basically put it like this to me when I told him the team wasn't succeeding: I'm here to demonstrate certain practices and to show that they work, not to just stop everything and attend to what the team is dealing with today."

To move forward through this crisis, we need to set new goals for software development management: To be close enough to the work to be able to manage work, and to use directed authority in service of helping the team meet expectations when creative enablement turns "self-organization" into entitlements for excessive experimentation.

And we need to re-define the role of coaches from servant leaders to temporary co-managers, helping the team to meet expectations while bully management and its detritus is transformed into effective software development management.

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

Manager or Bully?

2010-09-08T08:40:00.009-05:00

Management in the large: managers set expectations for their workers. Of course there's more to it, but "setting expectations" covers a lot of ground.

Management is central to the productivity crisis we face in software development. It's a crisis that pervades software development so profoundly that we usually don't recognize it. It's like water to a fish - not something that our attention is drawn to, not something that we notice. It's the environment that encloses everything we do. It's not that we see it as normal, we just fail to see it at all. Frustration, burnouts, blown budgets, missed expectations, and dissatisfied customers; it's just the way that most software development is done.

We start with the best of intentions, and despite our intentions, we usually end up in the weeds. We end up in the weeds most of the time because that is where software development teams are directed. It's because of one salient, painful truth about software development:

Software development managers don't understand the work of software development sufficiently to be able to direct the work of software development, and the value of hands-on work experience they've had in the past decays so rapidly that it's increasingly unsafe to make new decisions based on it.

Said more plainly: at a time when senior staff should be best informed by their lengthy and varied experience, they remove themselves from the work of software development long enough to lose the understanding of how day-to-day software development work is done. They lose the knowledge needed to direct the work of day-to-day software development. A certain egoic mania takes root that leads senior staff to feel entitled to believe that their insight has moved beyond the necessity of mere practical work experience.

How long does it take to become unqualified to set expectations for software development work? Not long. It happens as quickly as six months and often not longer than two years. This is why the proposition of Self-Directed Work Teams that has been popularized by new, opportunistic interpretation of Agile Methods has become so attractive in software development - even though SDWT is a well-known failure mode in most development industries and is known to be sustainable for no longer than a couple of years in the majority of cases (there are exceptions, but exceptional organizations usually aren't the rule for unexceptional organizations, despite our best hopes and ideals).

Plotting software development management on a continuum between the extremes of Managers and Bullies, we don't find many managers who are only either extreme. A software development authority is rarely either only a manager or only a bully, but software development managers are usually weighted more toward the bully end of the spectrum. It's an innevitable consequence of having lost interest in the details of software development work, and having become quickly dated as a consequence.

Someone who sets expectations but who isn't able to show workers how to fulfill expectations isn't managing, he's using the implicit threat of crossing an authority to make demands without knowing if those demands can be met. And he's hoping for the best. But we need more than hope to manage software development. We need to know that the work being done every day is the work that leads to the desired outcomes.

Setting expectations without knowing how to meet those expectations almost always leads to unqualified or unrealistic expectations. Using authority to require unrealistic expectations to be met always creates a compounding accumulation of obstructions to subsequent work. It's a sure-fire path to lower productivity. Most software development organizations live perpetually under this cloud of depressed productivity.

A bully sets expectations for workers but doesn't have the relevant and necessary capacities to help those workers fulfill the expectations. A bully has been disconnected from work for long enough that he (or she) is no longer able to personally act to ensure that his workers meet his expectations - to show them how the work is done, and to qualify the work that they do.

In other words, the person who needs to be the most experienced and most expert software development worker on the team is often the least capable.

A direct manager knows how the work should be done. He may know this better than his workers. When necessary, a manager can sit down with the worker's current tools, and teach the worker how to meet expectations, and to teach the worker how the specifics and tactics are tied to a greater whole. A bully hides behind assertions that his time and intellect are too valuable to be spent on such trivialities as the "how" of doing the work in his purview.

It's fair for a person with authority to no longer have the capacity to ensure that workers are materially able to meet expectations, but then that authority must defer to someone who does have the necessary and relevant capacity. And this is an entirely undesirable circumstance. It might be the circumstance that you're dealing with, but it's not the one you should settle for.

An authority who isn't capable of knowing whether and how work can be accomplished and whether expectations can be met is qualified to set only summary expectations. An authority who over-steps the material bounds of his capacity will continue to inject productivity obstructions into his organization's workflow by causing workers to make unsafe and counterproductive decisions that innevitably lead to rework, overwork, and relearning.

A bully believes that his workers are soft and lazy, and often puts extra pressure on workers believing that this is what it takes to get merely nominal productivity. A manager recognizes that workers who retreat from work are likely facing some distressing obstructions in the workflow. He uses his skills as a teacher and his insights into the work as an expert worker to help his workers to recognize and clear obstructions.

It's often hard for us to accept the cold reality of the depressed productivity in our organizations. We fail to manage software development as a product development discipline and tend to manage it as a manufacturing discipline (usually without even understanding or recognizing the difference), undermining productivity at every turn by tuning the wrong variables and turning the wrong organizational and procedural knobs.

In an environment where management leans more to the bully side of the continuum, we see work teams stretch the intentions of "self-organization" into the realm of "self-determination" or "self-direction". It's not necessarily an unwarranted reaction, but its a reaction to a root cause that should be the focus of organizational and procedural improvement. It's in these environments that we also see a need for coaches to fill in the management void, but this is also a lesser palliative that doesn't necessarily get to the heart of the matter.

A manager is someone who balances qualified and expert worksmanship with the ability to teach and is comfortable with using directed authority when necessary. He goes with his team into new learning and new understanding, and re-directs the team if the creative drive for experimentation starts to occlude the imperatives of delivering material product.

Doubtlessly, it's sensationalistic to divvy up the software development management landscape into extremes, but doing so is meant to frame the issue so that we can begin to recognize a real problem and begin to do something about it.

The way that software development is practiced at large, it's perfectly understandable for software development workers to become burned out on software development, and to look for a change. Unfortunately, moving upward to software development management isn't where people who are burned out on this work should go. It's little more than an escape, and it needs to be more of a deeper commitment to the work rather than a means to justify avoiding the details.

Ultimately, software development work will remain palatable for much longer when it is managed much better. But we are where we are, and the general population of software development managers will remain skewed heavily toward refugees from the work of software development for some time.

This is the software management crisis: software development managers at large aren't experts in software development work now, and they often weren't expert workers in the days when they were hands-on. They were the people who came to dislike the work enough to want to escape to software development management. They usually don't know enough about the details of the work to understand how subtle decisions can result in tremendous outcomes, and which decisions lead to tremendously good outcomes, or tremendously poor outcomes.

Today's software development managers largely haven't made a study of managing software development and the principles of product development work and work management. Software continues to be managed as one would manage material assembly or manufacturing. Our current generation of managers isn't aware of this problem because software development management hasn't really been a field of interest for most of them - it's just the job that they have, and it's one that keeps them from having to work in the painful niggling details of poorly-managed software.

None of this suggests that we need to wipe the halls of software development management clean and start from scratch with newly-installed personnel lifted from the rank-and-file. One of the worst mistakes that our current management ideology continues to make is the failure to recognize the material cost of losing institutional knowledge when we lose any worker (NOTE: the flip side of this problem is the colloquial horror of not knowing who to hire, and bringing people into our organizations that we dismiss in short order).

The software development mangers that we have today may have become burned out on the details of software development, but those details can be changed to make the work less tiresome, and make the work less like an uphill battle being fought on a cliff face rather than a gentle slope. Their institutional knowledge is far too valuable to lose. Their many years of experience - if paired with a sharper understanding of which decisions make software development good and which make it bad - provides a perspective of the whole of the effort that is invaluable.

It's entirely reasonable to expect that we can transform the software development industry. The root of the problem is in the software development management system. When software development managers are willing to look without flinching into the reality of their situation and the circumstances that have led to their positions, then we can begin to rehabilitate the system. When that happens, many of the software development industry's most futile pathologies will fall by the wayside and we'll begin to tap the potential that is this industry's unclaimed birthright.

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

Video: Ruby for .NET Developers (From the Norwegian Developers Conference)

2010-06-24T08:30:00.002-05:00

My presentation at the Norwegian Developers Conference, "Ruby for .NET Developers" is available for viewing on Vimeo.

There's a bit of off-color humor in the talk for the sake of making a point about orthodoxy, and done specifically-so for the European audience that it was presented to. So, no offense intended! :)

View it here or open it on Vimeo's site for more viewing options.

Here's the description of the presentation:

After having spent many years coding in C#, and after having spent equally as much time in the C# language culture, Ruby seemed like a lot of bad ideas and heresy. In fact, much of Ruby is heretical to a C# or VB.NET mono–culture, but the productivity gains demonstrated by Ruby on Rails teams remains an unavoidable elephant in the room. This presentation looks at C# code examples side by side with some equivalent Ruby code and shines a little light on what it means to have either "ceremony" and "essence". It challenges the claims of static typing's effect on tooling to deliver "developer productivity". And finally, some examples of Ruby meta programming are given to demonstrate direct solutions to programming problems that would require much ado with restrictions in C# that don't end up doing much more than reducing the efficiency of software development efforts.

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

Praise for the Norwegian Developers Conference - A Conference with Heart

2010-06-21T16:28:00.006-05:00

Leaving the Norwegian Developers Conference after the last session of the last day, conference participants were bid a fond farewell at the door by Kjersti Sandberg.

I suppose it's not such a big deal to have people saying goodbye to participants as they leave, but in the case of the NDC, the person doing the goodbyes was the conference organizer herself.

There is a lot to say about the quality and value of a conference like the NDC, but if you trace the outward expressions of quality back to the source of the quality, you inevitably find yourself staring square in the face of leadership. It's Kjersti's leadership that makes the NDC an excellent conference - and in my case, one of the best and most rewarding conference experiences that I've ever had.

When you build something that you truly believe in, and when you have intentions to do something great and hold yourself to extremely high standards, that sense of ownership is palpable in every aspect of the work and of the product. The Norwegian Developers Conference in Oslo last week was an obvious expression of leadership, vision, and commitment.

I get the sense that being at the door, in person, to bid farewell to conference participants wasn't just the execution of good customer experience technique and strategy, but was a moment for Kjersti to enjoy the fulfillment of hard work and excellent execution. I can't remember a conference where the conference director was so deeply invested in her customers' experience that she was there in person to wish them well and to express her appreciation for their participation.

Anyone can fake these kinds of expressions of customer service, but it takes heart to do it and to make it clearly sincere and meaningful.

Kjersti wasn't at the door to wish NDC participants a good journey back home and through the next year because it's just smart, personable technique. She was there because it meant as much to her to enjoy the moment of personal and personable accomplishment as the experience of the NDC meant to the people who came to NDC. And it was definitely a moment of absolute pleasure for me to watch something quite rare: a true appreciation for customer experience reflecting a true investment in product and customer development.

Kjersti wasn't at the door with a big sign over her head letting people know that she is the person behind the NDC. She was there anonymously. She wasn't there for the show and the display, she was there because it means something for her to be there, and to say farewell in person. It wasn't about a demonstration of investment in customer, it was simply investment in truth incarnate. For me, it was probably the most endearing moment of a conference that overflowed with endearment.

There's much more to say about the people involved in making the Norwegian Developers Conference happen. I'd just like to say thanks to everyone at Kjersti's company, Program Utvikling, and to Anders Noras, Rune Grothaug, Henriette Holmen, Jakob Bradford, Thale Sandberg, and a host of people who had a role to play in making the NDC a memorable and rewarding human experience.

The most important thing about creating a good conference is crafting a space for ideas and perspectives to come together - especially conflicting ideas and perspectives - to learn what new ideas can come from the experience, and to form new, higher order ideas that resolve what we had previously assumed were ideas of irreconcilable difference. It takes courage and integrity to create a space to allow this to happen. The space itself is just a blank slate, it becomes a space of courage and integrity when it reflects these qualities that are already qualities of its leaders.

Two salient takeaways for myself from my experience at conferences in Scandinavia:

Firstly, Scandinavian conferences, like NDC, Oredev, and others, don't seem to allow the kind of mindless orthodoxy that is eroding integrity in many conferences in the United States. They encourage encounters of diversity that, while tense, inevitably lead to the greatest ideas of the future, and point the way to the next steps.

And secondly, the United States conference market is in desperate need of a practitioner-level conference like the kind I've experienced in Scandinavia - especially in the Microsoft community, where diversity is increasingly avoided and, in some cases, actively suppressed. My hope beyond hope is that we'll see one of these conferences on our shores soon, and that their influence will help to get the community focused on goals that are more important to society as a whole than they are to the imperatives of a particular player's interests.

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

Ruby Meetup this Friday at the Norwegian Developers Conference

2010-06-14T08:00:00.008-05:00

This Friday at the Norwegian Developers Conference, the growing community of .NET leaders, influencers, and developers who have been developing in Ruby and exploring Ruby are hosting a Ruby Meetup during the conference lunch break.

Learn about how Ruby makes software development pleasurable and fun, .NET development with IronRuby, why web developers love Rails, the Ruby ecosystem and community, and why so many C# developers are adding Ruby to their kit.

Join myself, Rob Conery, Shay Friedman, Anders Noras, Ben Hall, Aslak Hellesoy, and a host of others in an informal gathering of .NET experts and Ruby enthusiasts.

Also, check out the Ruby sessions at the conference! This year's NDC has 5 Ruby-focused sessions on the agenda. As Shay Friedman says, the conference is the first to acknowledge the importance of Ruby to the .NET community.

Thursday

Ruby for .NET developers, Scott Bellware, 9am - 10am
IronRuby - A Brave New World for .NET, Ben Hall, 10:20am - 11:20am

Friday

Practical IronRuby, Shay Friedman, 9am - 10am
Riding IronRuby on Rails, Shay Friedman, 13:40pm - 14:40pm
Testing C# and ASP.NET Applications with Ruby, Ben Hall, 13:40pm - 14:40pm

See you at the NDC!

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

No Domain-Driven Design in Rails?

2010-06-07T16:16:00.012-05:00

The issue of why there is no Domain-Driven Design in Rails came up on the Herding Code podcast episode with Cory Foy and Will Green.

The inevitable question came up: Do Rails apps and developers take on less complex problems and therefore don't require Domain-Driven Design?

There's another question that we can ask which mirrors an observation I've heard form notable Domain-Driven Design (DDD) experts: Do .NET developers use Domain-Driven Design for problems that are far too simple to justify Domain-Driven Design? And... is the Domain-Driven Design used in .NET pop culture really Domain-Driven Design in fact, or is it a lighter Domain-Driven Design that leans mostly on the DDD pattern language and remains somewhat naive about DDD? If these questions are indeed valid questions, and if they're being asked by leading DDD practitioners, then is the question about Rails and DDD a question rooted in valid presumptions, or is it coming from a perspective that stands on shaky ground to begin with?

Here's an admittedly-provocative question: Do the .NET developers who are wondering whether Rails is for lessor apps (as evidenced by the absence of explicit Domain-Driven Design) actually have a firm grasp of what Domain-Driven Design is, or are they merely using a pattern language and suffering the self over-estimation that is far too common in technology orthodocracies?

I think there's a missing piece in the inquiry. We're failing to ask whether Domain-Driven Design can be accomplished with the Active Record pattern, or can it only be achieved with the Domain Model pattern?

Furthermore: Is the Active Record pattern the only model object pattern used in Rails apps?

Rails is often about the part of the app that often deals with user interaction, or more specifically: user agent interaction. Do you need to use Domain-Driven Design for this part of your app? Maybe you do. Maybe you already do. Maybe you already use Domain-Driven Design for this part of your app but you're not yet aware that you're only using the DDD pattern language to name archetypes and layer supertypes in your design. After all, it's not like there's a lack of precedent for this in .NET apps "using" Domain-Driven Design. It might even be the most common form of DDD in .NET.

One of the most salient teachings to come away from Domain-Driven Design with is Partitioning - conceptual, physical, and logical. Partitioning is reflected in Domain-Driven Design's Aggregate Root pattern, its Repository Pattern, and its Bounded Context pattern, amongst others. The increasing attention given to eventual consistency and Command-Query Responsibility Separation (CQRS) in context of Domain-Driven Design also reflects partitioning and its effects and considerations.

Rails' - the framework - has absolutely nothing to say about partitioning. And its not supposed to. Partitioning is about a solution's topology and architecture. Rails is about building the user-interactive strata of an app. What you do behind the scenes is entirely out of Rails' hands. Rails itself - including its models - are a descriptive DSL over the abstractions that are over the infrastructure. You can make Rails archetypes as loosely or tightly coupled as you want (although you might be taking the Rails part of your app in the wrong architectural direction if you pursue extensive schema de-coupling, and you might need to be a pretty solid Rails hacker to do so).

That said, the Rails ecosystem has built a plethora of plugins for the framework that allow these architectural styles to be accommodated in a solution where Rails is in-play. In the wild, partitioning is one of the most obvious aspects of solutions that are front-ended by Rails.

Large-scale apps like Shopify, Gowalla, GitHub, Hulu, Scribd, Highrise, Yellow Pages, etc, don't get built without partitioning, and separating write from read operations. And you can't build a Rails app without modeling - whether you do modeling in your head, in code, or with diagrams (all are supported, bu the way). You can't build any of the non-public line of business Rails apps being built by organizations like Amazon, Electronic Arts, IBM, JP Morgan, NASA, Yahoo, Rackspace and a host of others, without tackling complexity at the heart of software design, and doing so in a way that insulates the non-complex part of your app with the complex part of your app, and dealing with them on their own terms without one tripping all over the other.

So, is the Active Record pattern sufficient for building Domain-Driven Design apps? Again, it goes back to how much you feel you should drive the whole topology and architecture of your whole solution from a framework that is intended to serve one aspect of solution architecture.

Domain-Driven Design is often trivialized to being merely a ubiquitous language (which is yet another DDD concept that itself is often trivialized into a meaninglessness that ignores other DDD precepts), entity classes, repository classes, service classes, and specification classes, and a smattering of other often-obscured concepts in the DDD heritage.

There's still something to learn from this form of DDD, but let's get serious for a moment: it's often just DDD as a pattern language, or "DDD Light" (now with 90% less real complexity!).

The average .NET app using Domain-Driven Design could, in my experience, be done for much less if done in the Rails ecosystem. Apps that use DDD inappropriately sometimes even end up needing more DDD because developers and designers have added insurmountable accidental complexity. There's nothing that contradicts DDD's essential message more than adding complexity to a solution!

Active Record, Rails, and Ruby, used in the parts of an app where its appropriate, don't contradict DDD. Without any question, it absolutely will change the pattern language used to describe the part of the app where you use Rails - but usually, that's all it does. If all you can see of Domain-Driven Design, however, is the pattern language, then you likely won't be able to use Domain-Driven Design even when you believe that you are using it.

There's little need for a Repository archetype in Rails. That said, Rails apps often do exhibit the essence of the repository pattern in the resource-oriented idioms (Aggregate Root, Repository, Specification, Context, Contours) that are ubiquitous in the Rails developer and architecture culture. Do you need to have a Repository class in order to be responsible about partitioning and to provide collection-oriented semantics for aggregate root access? For that matter, can you build a Domain-Driven Design app in programming language that doesn't have any notion of what a "class" is? If you can't have a Repository class can you still do Domain-Driven Design?

Do you ever hang data access operations off of a Repository class that aren't consistent with Repository or Aggregate Root semantics? Ever pull a lazy-loaded instance of Product from an OrderItem instance without going through a Product Repository? The question here isn't whether you've violated DDD in this case, but whether DDD's necessary constraints serve you well in these situations, and whether you should be trying to impose these constraints on this particular part of the whole architecture.

In my experience, there's as much Domain-Driven Design happening in the Rails world as in the .NET world. The big difference is that in the Rails world there's no social capital to be gained by speaking in the DDD pattern language in social gatherings of programmers trying to make their way in the professional world. Rails developers tend to just point to the game-changing web innovations and properties they've built and leave it at that.

One last thing about Domain-Driven Design and .NET: .NET developers tend to not recognize that using DDD as a pattern language is in essence a way to have an elaborated pattern language for Dependency Injection, as the design archetypes borrowed from DDD are usually either layer supertypes or archetypes of injected dependencies in static languages.

DDD Light is a side-effect of a programming paradigm where composition can largely only be achieved through Class-Oriented Programming. When the paradigm changes, and composition is something that the language itself can do, the propensity for DDD Light tends to dissipate. And that is why you tend to have less explicit mention of DDD in Rails' culture. DDD Light is as necessary in Rails as explicit, class-oriented composition and static dependency injection is. That's to say: it isn't (always). This was another topic briefly touched on by the Herding Code episode.

The necessity for Domain-Driven Design in fact and in practice in Rails is already well-established. Rails folks are just less-interested in talking about it in DDD terms, and not at all interested in DDD Light, as it's orthogonal to the paradigm - both socially and technically.

Rails - the culture and ecosystem - doesn't do DDD Light as the .NET culture and ecosystem does. That's about all we can really say about Rails and DDD.

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

Monospace: .NET Open Source Social at the Norwegian Developers Conference

2010-04-20T07:30:00.008-05:00

I'm very excited to be working with the folks at the Norwegian Developers Conference (NDC) in Oslo from June 16th to 18th on a very special event.

On Wednesday evening, June 16th, we'll be celebrating open source software in the .NET space with members of the Mono Project as well as NDC speakers and attendees from the .NET open source community, and the open source curious. Cap off your day with complimentary refreshments and a look at some of the community projects that have changed the face of .NET.

Did you know that you can run .NET applications on iPhone and Android using the Mono Project's open source implementation of the .NET stack? Mono will also let you run your apps in powerful and mature cloud platforms like Amazon EC2 and build for special purpose hardware platforms. Want to deploy your apps to Linux and Mac? No problem, that's what Mono does for you. Use your C# skills to go further than you ever thought possible, and you don't even have to leave Visual Studio!

Not only has the open source community made cross-platform .NET development a reality for all .NET developers, but open source provides a wealth of development tools that have become the leading indicator and the gold standard for where .NET software development is heading. Unit testing, ORM, build scripts, UI testing, MVC, continuous integration, source control... all of these fields were led by open source efforts years before they started showing up in commercial products. Stop waiting to find out where .NET development is going! Come to Monospace and greet the future right here in the present!

If you don't have any experience with open source, join the party and see what the fuss is about. Learn about the wealth of tools available to you as a .NET developer, made available by some of the most accomplished and expert developers in the community. Get your questions answered by the pros, and get tips on how to augment your projects and your skills with the vast array of mature, stable, open source tools and products. This event is for you. You don't have to be an open source hacker to enjoy Monospace. Stick around and indulge your curiosity!

If you're an open source user, add your voice to the conversation. There will be plenty of .NET developers with questions to answer and experiences to share. Participate in discussions and demonstrations and even get a chance to learn about projects that you haven't heard of yet. Bring your laptop and sit down with open source contributors and users for a little hacking and show and tell!

Join Jackson Harper of the Mono Project, as well as myself, and many of the NDC speakers and attendees for a fun night of sharing and networking at the Monospace social.

Check out this list of NDC people who are open sourcers: Rob Conery, Scott Allen, Ben Hall, Roy Osherove, James Gregory, Greg Young, Jon Skeet, Robert C. Martin, Michael Feathers, Louis Dejardin, Sebastien Lambla, Shay Friedman, Anders Norås, Kevlin Henney, Lisa Crispin, Richard Campbell. And that's just a partial list! Come out to Monospace and find out what attracts these leading thinkers and practitioners to open source solutions.

Expand your .NET horizons at the Monospace social at the Norwegian Developers Conference. Information, links, and more at: Monospace.us

Also, checkout the NDC conference agenda for great sessions on Mono and .NET open source at: www.ndc2010.no

Many thanks to the Norwegian Developers Conference for supporting and sponsoring the Monospace social, and for making it happen.

See you there!

IronRuby Drops - Does it Make a Sound?

2010-04-15T15:42:00.009-05:00

Phil Haack, Program Manager for ASP .NET MVC commented:

"IronRuby RTMs!? Put that in your pipe and smoke it @Bellware. The asymptote has collapsed!" (original tweet)

I quipped with Phil when he was in Austin a while ago that, "IronRuby is asymptotic to shipping", which is the inside joke he's referring to. The point being that IronRuby has taken long enough to ship that it's dangerously close to that point of a multi-year software project where it may not be able to cross the last mile.

IronRuby has indeed crossed the last mile, and on April 12th, Jimmy Schementi and team announced the availability of IronRuby 1.0.

A hearty congratulations to the IronRuby and DLR team for getting IronRuby done, and to John Lam for getting the ball rolling with his RubyCLR project in 2006. It's a great accomplishment and another feather in the cap for the ever expanding diaspora of Ruby implementations, and most definitely a giant leap forward for .NET development and programming.

Enter ASP .NET MVC and the Loss of an IronRuby Vanguard

The furor surrounding Ruby isn't now what it was three years ago when IronRuby was announced. In the .NET community, the attention given to Ruby on Rails two and three years ago has largely subsided. The audience has had its attention redirected to ASP .NET MVC. Ultimately, I see this as a loss not only for IronRuby, but arguably also for the community.

There are a lot of newly-minted MVC developers in the web development community of .NET developers. I'm skeptical about comparisons made between ASP .NET MVC and Ruby on Rails by folks in the .NET community who haven't shipped a Rails project. These comparisons are often shallow and uninformed by experience. They're also not peer comparisons, and tend to point out things that one framework has that the other doesn't without consideration of whether these features are useful in both paradigms (yes, I sometimes use view models in Rails, I just don't require their signatures to be frozen before runtime so that static analysis tools have an easier job of it).

The ALT.NET community would have been the audience that was best-prepared to perceive and leverage the power of Rails, arguably via IronRuby, but instead it led the vanguard into ASP .NET MVC.

There is a tremendous wealth of uses for IronRuby but Rails has been the usual gateway to broader adoption of Ruby. With the Alpha Geek's attention redirected to ASP .NET MVC, the gateway isn't being crossed by the .NET intelligencia the way that it was by the Java community intelligencia that was ALT.NET's most influential inspiration.

For folks like myself who've invested enough effort to understand why some of our most respected teachers moved from Java for web application delivery to Ruby and Rails, there's no meaningful comparison of ASP .NET MVC to Rails.

While ASP .NET MVC has made significant progress in the past two years, it progresses at a snail's pace. We can contrast ASP .NET MVC's technology to Rails' technology, but this is the typical mistake that .NET developers make when trying to compare ASP .NET MVC to Rails because ASP .NET MVC doesn't have a whole ecosystem on the magnitude of the Rails ecosystem. This ecosystem includes not only the core framework technology itself, but the vast number and quality of plugins and packages for Rails (including those built for general Ruby development), the integrations with value-add services for both web businesses and web infrastructure, the vast array of hosting options and architectures, and the brain trust residing in the Ruby and Rails community.

Through a few years of working in Rails, I've come to a deeper understanding of Ruby (but I'm still no expert). And through this experience I've come to look at my own previous feelings about C# and static programming as a little shallow. It doesn't in fact amount to a personal preference, as many monocultural programmers have suggested to me. It's a matter of rational analysis and a willingness to accept the results of that analysis even of it contradicts my strongest feelings, my current preferences, and creature comforts.

After working with Ruby for some time, it started to become absurd to me to continue to build dynamic, adaptable systems with languages that aren't a great fit for this kind of work. I began to see that static design patterns were inevitably a mostly-wasteful workaround for trying to implement composable designs with languages that are hostile to this goal. I came to see that I was personally stimulated by the efforts to solve these dynamic programming problems with static languages. And I came to see that I wasn't being paid to put myself in the way of interesting but non-essential puzzles just to have a chance to solve them. There are other problems to solve - productivity problems, most notably, and business problems.

To me, this meant facing a hard inevitability: the de-emphasizing of a skillset that I had worked years to acquire, and a commitment to re-learning. The payoff, I knew, would be a reward in greater productivity and elevated conscious awareness.

I'm still learning, but there are many things that I have already learned in the past three years. One of the most important things that I have learned is that solving dynamic programming problems with static programming languages - while stimulating - is counter-productive except as a performance optimization. And even at that, I might consider alternative solutions, as GitHub, Twitter, and others have done in exploring high-performance, message-based, actor model functional languages like Erlang, a technology underlying new orders of performance technologies like CouchDB and RabbitMQ.

Most of all, I learned that even some of the most progressive .NET developers - even in today's ALT.NET community - are driven by a trepidation over a programming life without Visual Studio, and by association, ReSharper.

I've cautioned for sometime that there's a disturbing tendency toward what I've called "ReSharper-Driven Development". Far too many developers don't find anything wrong with saying, "I won't consider developing without ReSharper". I'd rather hear developers say, "I won't consider letting anything get in the way of my discovery of sources and paradigms of productivity and effectiveness that I simply haven't considered or can't conceive of yet".

I've got nothing against ReSharper, Visual Studio, or any other advanced development workbench (like RubyMine, for example). I was in the first wave adopters of ReSharper, and I was the first member of the community to have sponsorship from JetBrains for ReSharper. I was also a user of its predecessor, C# Refactory, going back to Visual Studio 2003. Nonetheless, I'm also willing to use a much more light-weight editor like TextMate or MonoDevelop. After twenty-some years of playing guitar, I'm also willing to pick up any guitar I can get my hands on just to have an experience of it, knowing that I'll be enriched by the diversity of the experience, and to know that this diversity is the foundation of my ability to continue learning at a pace that matters and to counteract the human tendency toward intellectual contraction and conservatism that is the inevitable side-effect of long-term, focused experience.

ALT.NET without the "ALT"

Some time in late 2007 I proposed "Integrity, Courage, Diversity" as ALT.NET's credo and motto. It didn't go too far and I didn't pursue it. It wouldn't be too long afterward that I'd realize that community leaders with great influence would begin to make exceptions for themselves in entitlements to using ALT.NET not for community service, but to justify efforts in celebrity-seeking as conveniently-beneficial to the greater good. ALT.NET became a launching pad for yet-another-BDD-or-MVC-clone-framework in the .NET space, as well as a way to secure increasingly more high-profile public appearances.

I didn't agree with David Laribee when he turned his attentions to means to "monetize ALT.NET". ALT.NET had barely established an unshakable foundation in diversity, courage, and integrity and had ultimately begun to come under attack from a myriad parties who wanted it bent to promote this or that bid for materialistic entitlement. It was like watching those parents who are willing to take their toddlers to auditions for movies, commercials, and pageants before the children had become self-actualized in their own sense of integrity. It was too soon. As clear as this was to me then, it's painfully and crystal clear now.

I don't agree with Jeremy Miller, creator of the .NET MVC framework, FubuMVC, who has suggested that .NET has now matured enough be as satisfying as Ruby and Rails. I think that this is only true from a place in life where we're driven unconsciously by the pleasure of solving static programming patterns problems.

I don't agree with Chad Myers who has implied that FubuMVC has advantages that Rails doesn't, without considering paradigm differences in working with Rails that may negate the value of things that may be advantages to static language pattern development.

I took heat from ALT.NET community members when I founded the ALT.NET Summit in 2007, introducing the .NET community to Open Space, and pushing a meme beyond the tipping point that within a couple of months of Dave's coining of ALT.NET had already started to fade into the typical background noise of fleeting fads. I took heat for building the conference website in Rails, stopping an on-going project to build the site on MonoRail after reviewing the site's code written in C# and realizing that the Rails equivalent would be much more elegant and less frustrating to deal with the torrent of frequent updates that hit a conference website in the weeks leading up to the event.

I have a profound respect for Dave having followed suit, building the altdotnet.org website on Rails rather than .NET, learning from experience, and making decisions informed not only by unconscious attachment, but also by experience shipping a project on a technology. I also think it's laudable that Dave's blog is built on WordPress, demonstrating that working with .NET doesn't require you to publish on CommunityServer, and that there are best-of-breed solutions outside of .NET monoculture that are preferable - whether they stimulate your current creature comforts or not.

ALT.NET was founded as a movement, even though the movement has been all but cleansed from the ALT.NET culture and history. In the redacted quote of Dave's original communication of ALT.NET to the community that holds a prominent position in the altnetpedia website, the following quote from Emerson is conspicuously absent: "there are always two parties; the establishment and the movement". Dave goes on to say, "If you’re ALT.NET, you’re in the movement. You’re shaking out the innovation. When the movement fails, stalls, or needs improving you’re there starting/finding/supporting that next leap forward."

Today's representation of ALT.NET stands in stark contrast to what people like myself had invested years of work in studying, practicing, teaching, traveling, meeting across the aisle, negotiating, volunteering, community organization, activism, lobbying, protesting, triumphing, sometimes losing, constantly sustaining and persisting in the face of an entrenched entitled cast of Microsoft community characters, and not just a small amount of personal sacrifice to build.

And while Jeremy has gone to great lengths to misrepresent the many years of dedication as a "holy crusade" and thus make it unpalatable for members of the ALT.NET community to expect the same commitment of themselves and thus of the community leaders that have not abandoned what ALT.NET had become, ALT.NET's diversity, integrity, and courage continues to become increasingly irrelevant considerations for the community.

And as diversity continues to erode, and mediocrity continues to accrete in mainstream .NET, so it does in ALT.NET as ALT.NET becomes the same kind of cultural body as the mainstream that it had intended to provide an alternative for. While ALT.NET adopts the exact same social mechanics as the mainstream entrenchment in serving the celebrity-seeking entitlements, great advances like IronRuby fall by the wayside if they represent inconvenient truths to what is now an ALT.NET establishment.

An Alternative to the Alternative

If the ALT.NET community continues down the path of fear into the exact same kind of tool-driven development behaviors that it criticizes Workflow Foundation and Entity Framework users for, it will undoubtedly miss the incredible opportunity that IronRuby lays at its feet.

ASP .NET MVC is not a peer to Rails. Not by a long shot. C#, even with the dynamic keyword, named parameters, and extension methods, is not a compositional language like Ruby. There is more power in this framework, language, and ecosystem than .NET developers - be they mainstream, ALT.NET, or progressives - may have had the occasion to understand.

If you value your experiences with MVC, then you might value the works that ASP .NET MVC has attempted to interpret, largely creating a low-fidelity facsimile that is generations behind the originals. If you're a patterns developer, an agilist, a test-driver, and an amateur of forward-thinking, no-limits technology communities, then the Ruby community - to my eyes - has more to offer you than what has become of ALT.NET in its present incarnation.

You don't have to leave .NET and Windows to experience Rails and Ruby as many notable .NET influencers have - although, like them, you might decide that .NET and Windows are unnecessary to building great web products. Nonetheless, now you have a choice.

You also have a choice to continue to have your attentions re-directed to lessor solutions. But understand that now that IronRuby has dropped, you're choosing lessor .NET solutions. And while it might be understandable that you aren't comfortable with anything other than Windows, you can experience Rails on IronRuby and use IIS as your application server.

And best of all, in the original spirit of ALT.NET, you will have a universe of alternatives available to you if you choose to take advantage of them. Alternatives that include:

Immediate support for RESTful design and resource-oriented MVC
A more mature and fully-featured routing engine including route helpers
A better plugin model with orders of magnitude more available plugins and service integrations
A package distribution system right now with Ruby Gems
Hosting in the cloud without constraints using platforms like Amazon EC2, Rackspace, Engine Yard
Managed cloud fabric like Heroku if the bare-metal cloud doesn't suit you
More mature client libraries for emerging high performance storage, caching, application server, and middleware technologies
Being in a social and business community that builds game-changing products and services like Hulu, GitHub, and Twitter
Participating in the community that is making the greatest advances in TDD and testing tools and methodology
And best of all: being able to look back a year from now and realizing all that you've learned about what you thought you knew :)

Resistance

You're going to face resistance and maybe even vilification in some cases in the .NET community if you make such a move. If you value the courage that progressive software development is all about, you'll weather the storm and build character in the process.

If the ALT.NET community had stayed on-target with Ruby and IronRuby, there would be a good number of popular bloggers who might loose their audience. You're not in this profession to provide those with a sense of ongoing entitlement to a perpetual audience with even more entitlements. It's not your job to sit at the feet of static pattern puzzle-solving masters in a time when the necessity of those puzzles is simply no longer an absolute.

There are a whole set of patterns waiting for your discovery and participation, and they don't require you to obscure the intension of your code with compiler pragma noise like interface types, generics, and casting.

If you like to have your brain tickled by patterns, check out Design Patterns in Ruby (and consider paying close attention to the last section which offers patterns specific to Ruby and dynamic languages), or the Smalltalk Best Practice Patterns book by Kent Beck.

Stop waiting for the next immature .NET pseudo-port of a Ruby project. Just use the Ruby version. You don't need a .NET version of Gems just so that some social-climbing .NET open source celebrity-seeker can take a firmer grip on your attention. Just use Ruby Gems. Heck, you could use Ruby Gems right now for your .NET package management.

Stop waiting for ASP .NET MVC to catch up to Rails. Didn't you adopt open source to begin with because you were fed up with waiting for Microsoft's snail's pace of innovation and sunk-cost product management politics to catch up to the level of your expectations?

Despite Jeffrey Palermo's recent flattering of the ASP .NET MVC team's understanding of Test-Driven Development, Phil Haack and team were deeply in the weeds when it came to TDD, and to the credit of Phil's courage and integrity, he's left remnants of those difficult times in the clear for others to learn from. Making mistakes in public and having a consistent persona both on-camera and off are critical to establishing a community of integrity. The remnants of leadership in the ALT.NET community could learn a lot from Phil about this.

The repercussions of some naive MVC framework design decisions in ASP .NET MVC may never be rooted out of the framework because of Microsoft's bureaucratic policies regarding the need for near-infinite backward compatibility for those massive corporate Microsoft customers who cannot create the kinds of learning organizations that mitigate these kinds of problems. Rails, on the other hand, simply does not labor under the same drastic limitations.

Burn Me! I'm a Witch!

I know that I'm going to catch more heat for this article. People will say that I'm unrealistic to think that .NET shops can adopt Rails, although I, and many others, have led .NET shops through Rails adoption. They may point to the Rails project failure at Dovetail as an example without pointing out that the current project at Dovetail is more than 100% over-budget, and seems to produce more open source and celebrity than money. Mention of product and team management failures at Dovetail might also also be neglected. We shall see.

It may be said that I'm out of step with what ALT.NET has evolved into (something that I feel an immense source of personal and ethical accomplishment about) without pointing out that I'm still dedicated to living my professional life as an example of on-going community service, knowing that through the many years that I have been doing it have shown me that seemingly insurmountable changes can be made in relatively short periods of time with a community of practice focused on bigger goals than celebrity entitlement.

And most trivially, my lack of talent in structuring short, clear sentences may be used to malign the message that they contain in an effort to continue to sideline me and my perpetual pleading for more critical thinking driven by experiential learning and community service in the .NET community.

I haven't stopped asking the .NET community to stretch out beyond Microsoft's own sunk-cost imperatives - not since I founded the Austin .NET User Group in 2001; not since becoming chairman of the INETA speaker committee and working to get more progressive speakers involved who weren't purveyors of Microsoft's message; not since getting involved with DevTeach years before the vast majority of you had heard of it and working toward a day when the conference would feature progressive topics; not since organizing the ALT.NET Summit in an effort to insulate it and the practices that it advocates from the ravages of fleeting fad; not since writing and organizing the popular movement to redirect the Entity Framework team into more responsible and sustainable design (and subsequently quietly teaching them a Test-Driven Development workshop sans compensation); not since putting my MVP status on the line for my principles rather than allowing it or money gigs with Redmond to modulate my values; not since establishing the Progressive .NET events in London and Stockholm to encourage teaching in the .NET community rather than just speaking (although the celebrities that I'd gotten involved in that event have since refuted any responsibility to form a teaching practice and I've distanced myself from the events); not since organizing the Monospace events in Austin and Oslo to promote open source and diversity in the .NET space; not since working with the Austin Software Mentors group who are tutoring University of Texas students on contemporary software development techniques to prepare them for the real world after graduation; not since founding and facilitating the Lean Software Austin group to deepen the dialog in our community about meaningful productivity above and beyond celebrity agile; and not since connecting countless software developers to countless opportunities free of the mindlessness that accretes around entrenched entitlement power cliques in the Microsoft community.

And I'm reaching out to you again - asking you to reconsider your adoption of ASP .NET MVC over Rails and your fixation with editor-assisted programming and design over using IronRuby and Ruby.

There's an amazing world of capabilities that you've yet to discover far beyond static design pattern puzzles and ReSharper-Driven Development. There's a seed of courage that I'm counting on that I hope is still alive and well in .NET community even if it has been dormant for some time in the cold leadership vacuum left behind by the abandonment of .NET by some of our best and brightest.

In the end, you live your career life for yourself and not for me. And hopefully you won't be living it for the pleasure of folks who benefit from keeping you bogged down in a status quo that serves their interests more than yours. I may be asking you to take a more giant leap than you're ready for, but at least I'm not asking you to choose stasis. And I hope that the personal sacrifices that I've made for .NET community over the past ten years have left a modicum of credibility that would have you consider this:

IronRuby has dropped. Hear it? It will change your outlook on so much of what you do as a programmer and open you to a much broader world of software development and possibility. Trust me on this one. I've never given you a reason to doubt that I'm in your corner; that I've got your back; and that I'll drop what I'm doing to spend time with you learning and teaching rather than defending the fiefdom of my own .NET celebrity.

IronRuby isn't a magical vessel that holds mystical truths, but it just may be the next leap forward in your programming that Dave hinted at back in 2007 before all of this proceeded from movement to establishment.

Speaking at the Lean Software and Systems Consortium Conference in April

2010-02-17T18:28:00.003-06:00

I'll be speaking at the Lean Software and Systems Consortium Conference, taking place in Atlanta from April 21st to 23rd.

My talk addresses the more egregious losses of productivity that come from working with HTML specialists in rapid startups, and how to shape the work, workflow, and team system to leverage the power of specialists without incurring the specialist tax.

Abstract:
Web designers are highly-specialized professionals. We lose a lot of productivity due to the effects of this specialization, whether through rework, scrap work, relearning, or missed expectations. Rapid startups expect to be up and running within two months, from the start of development work to business launch. Web designers are critical members of web startup teams, and learning to deal with web design specialists is vital to a rapid startup’s ability to sustain its pace. This presentation talks about two web startups that applied lean thinking and pull and flow to this particular challenge, and the techniques and understanding that came from the experience.

Check out the full agenda on the LeanSSC conference website:
http://atlanta2010.leanssc.org/agenda

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

Productive by Design

2010-02-10T13:49:00.004-06:00

(Continued from: How the Mainstream Lost Software Development Productivity)

Productive designs are compartmentalized. The parts of your software are shaped to the way that your mind holds on to them. "Abstraction" means the same thing to software as to thinking. "Concern" is another word the shows how software reflects thinking. A software "concern" is something that I have put my focus on that is my present concern.

The compartmentalized bits of software are the shapes of your software's parts. The shape of your software and its parts is only one aspect of your software's design. The shapes of your software's parts is a "static design". "Schema" is another word for it. The other aspect of your software's design has to do with what happens when we bring the parts together, give them a problem to solve, and give them the green light.

We lose software development productivity to relearning and to misunderstanding. The design quality issues that makes it hard to learn, re-learn, and understand your software also make it hard to understand how it works and whether it works. Powerful tools that optimize the moment of creation of the parts of your software enhance your ability to lower productivity.

"Module" is another word for "compartment". A class is a module. Modular design has to be productive not only in its shape, which helps us understand how the software is broken down into concepts, but also in how those parts do some work, and how they work together, and whether they leave their tools out where you can trip on them in the dark.

Software is a machine. It's not a machine like your car's engine or your cordless drill, or like any machine that is made with material. Analogies to physical machines break down almost immediately. There are no machines in physical space that are anything like software machines. They're machines that run individuals' personal way of thinking of how to solve a problem. There are as many ways to program a solution as there are programmers.

Software is a machine. It's made of parts. The word "soft" in software says that it's easy to not only change the working of the parts, but also the shapes of the parts, and to even move the workings to a different part (which often then tells you to change the shape again).

The first great matter of software development is proving that the new shape of some part of your software will still do what you expect it to do when you turn the machine on. The second great matter of software development is whether the shape that you've given to the software will continue to make sense, and that the workings of the software are placed in the right parts.

There's one gigantic difference between working on software machines and working on physical machines that bears mention:

The parts of physical machines wear out, and we replace them with another, new copy of the same part. This doesn't happen with the software parts that you make. When we change software parts, we don't replace ones that have worn out with new parts from the same mold. When we change software software parts, we change the very shape of those parts, often re-shaping the parts around them as well, and moving the workings of one part to a different part, or even a new part created on the spot as part of a new compartmentalization. In relation to a physical machine, software is much more like the mold than the product. Software development is closer to die making than stamping.

Every time you make a change to a software machine, there's a good chance that the change shows up in an adjacent part, and there's a good chance that it'll show up when you're not looking at it. It's a lot easier to get the code you're looking at right than the code your not looking at. That's what "control and observe" is talking about.

To increase the chances of software working as expected after you've tried to turn a part of it into a hat, a broach, or a pterodactyl, you make observations of it. If the only way that you can observe the functioning of the part is to bring the whole machine online, your productivity is many times less than what it should be. If you can make easy observations of the part that you're working on (and maybe parts in the vicinity), you can also make those observations while you're working on it so that not all of the steps are wild leaps into the yonder.

Imagine software that routes baggage from an airline check-in desk through the bowels of an airport's network of conveyor belts and scanners until it arrives at the right gate for the airplane that you're traveling on. Let's say you reshape the part of the software that figures out whether to route baggage to gate 1 in terminal A or to gate 2 in terminal A. Same terminal, different gate. You're losing productivity if you have to start the process from the part of the software that decides to route the baggage between terminal A or terminal B.

Here's the problem:

You need to observe the gate router, but you must control both the gate router and the terminal router. Controlling the terminal router now is wasted work.

You need to feed the terminal router with the circumstances so that you're controlling it to choose the terminal A route. You also feed it the circumstances that it passes on to the gate router so that it does the thing that you expect it to, and so that you can observe that. The terminal router is superfluous in this scenario. You're concerned with the gate router, but you also have to be concerned with the terminal router's workings, even to the point of being concerned with how it gathers the information from its inner workings to pass to the gate router.

If your concern is the workings of the gate router, then you should only have to control the gate router, feeding it the information it needs directly without going through any intermediaries. It's what "separation of concerns" is talking about. Collusion of concerns makes you write more code (and more complex code) to make observations about your software, but it also throws attention switching into work that is trying to be a feedback loop.

If you have a gate routing module, you can likely control it and observe it directly. But what happens when you want to control and observe the terminal routing module? The terminal router will immediately pass the baggage off to the gate router after it has done its work. Can you control the workings of the terminal router without also having to feed it the right information that it needs to feed to the gate router so that the gate router doesn't accidentally raise an error? In other words, how do you control and observe the terminal router without having to be concerned about what the gate router needs to know to do it's job. If there was an accident rate in software development like there is in other production jobs, it would be measured by how often we accidentally have our attention sucked too far into a wood chipper of dependency inversion.

With the right modularity, you've addressed the "static design". The "dynamic design" is how the parts of the software are put together to make the machine. A software machine is put together at runtime, usually by something called a front controller. A Main method is an example of a front controller. So is the thing that receives an HTTP request and sends its instructions it to the right part of your application. This is the part of design that a lot of developers don't recognize as the sore spot of their productivity problems.

There some esoteric terms for this issue of controlling which modules you have to be concerned with when making observations. Much of the language is more complicated than the actual work that you have to do. If you don't get distracted by the lingo, you'll find that this is not only one of the most important problems to solve, but also one of the easiest!

If the part of your software machine that routes baggage from the check-in desk to the right terminal passes control to the part of the software that routes the baggage to the right gate, then the terminal router will likely need to call a method on the gate router (or send a message to it). If I just want to control and observe the terminal router without having to be concerned with the gate router, then I've got problem that can be solved by getting the terminal router to use a dummy gate router instead of the real gate router. I can't change the terminal router code so that it doesn't use a gate router at all when I'm trying to make these observations, because that's not the code that would run live anyway. It wouldn't be a real observation of the thing that I'm concerned with in the first place.

If the terminal router uses a dummy gate router, I don't have to be nearly as concerned with it as I am with my primary concern, which is the terminal router. This is what "separation of concerns" is talking about.

The last thing that you have to solve is a way to switch the gate routing part for a dummy gate router. That's not a hard problem to solve. If you have a terminal router object, you can create a constructor that accepts a fake gate router. The terminal router's default constructor can create a real gate router. When you need to observe the terminal router's workings, create a dummy gate router object that doesn't have to be more talented than not raising errors when it's not supposed to and pass it to the terminal router's constructor.

The term for this pattern is called "inversion of control", or "dependency inversion", or "don't distract me with superfluous concerns".

This is a really simple way to get superfluous concerns out of the way so that they don't interfere with the parts of your software that you're actually concerned with. The above technique is sometimes called "poor man's inversion of control". There are many free libraries that you can use to automate all this stuff and make describing how the parts fit together effortless (or better, unnecessary). They are "dependency injection frameworks" or "inversion of control containers". I like the word "composer".

The dynamic side of productive software design is all about putting the parts of the machine together when your system starts up (or on-demand). The effort that you put into the static parts of the design - the shapes, the geometry, the abstractions - is paid off when you're in complete control of which parts are in-motion when you need to make observations of your software. And to belabor the point: it's the ability to control and observe your software that will give you more productivity, or to restore your productivity. You can't use what you can't understand, and you can't understand what you can't control and observe.

If you can't directly control and observe your software, you might be mistaking efficiency for productivity. You're optimizing your work within a range of improvement that is too close to the floor that make a difference in how you to get the lid off the cookie jar.

Productivity is right there for you to reach out and harvest. It's locked up in your code like potential energy waiting to be turned into kinetic energy when you free it from its moorings. You can find it in all the ways that design interferes with your ability to work with the software that you already have. There's little value in optimizing the pace that you create new software if you're optimizing the pace that you incur compound interest.

Productivity is usually something that you free from your software rather than something you add to software. You create the interference. If you don't want the interference, don't add it to your software.

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

How the Mainstream Lost Software Development Productivity

2010-02-08T04:54:00.006-06:00

(Continued from: Denying Productivity)

The greatest software development productivity comes from software that can be easily and readily understood. When you need to make changes to software, you can easily and readily understand the repercussions of those changes. When you need to add new abilities to software, you can easily and readily understand where the additions need to be made. When you're new to an existing project, you can easily understand the code that has already been written by your new team. Understanding how to design software so that you're able to easily control and observe it gives you the ability to create software that can be understood, and software that doesn't obstruct productivity.

Despite the number of software developers who understand the mechanics and principles of software design that cultivate software development productivity, the vast majority of software developers don't understand how to wield the techniques, or aren't convinced by the promises, or simply haven't heard about higher order developer productivity at all, let alone how to get it.

Somewhere along the line, the software development mainstream lost its access to productivity, and the vacuum was filed with counter productivity or productivity proxies.

Two things contributed to the mass extinction of software development productivity in the mainstream: Eggheads and Shills. The eggheads allowed a divide to open between the intellectual haves and the have-nots, and the shills exploited that gap, filling it with misinformation and misrepresentations, verily redefining "productivity" and supplanting it with mere efficiency.

Yes, these labels are chosen for shock value. Specifically because this is an issue that is largely rooted in unconsciousness: the unconsciousness of failing to communicate, and the unconsciousness of deeper meaning.

I've learned quite a bit about software development and design from some very insightful and intelligent people. I'm grateful to the authors who've been my long distance mentors and who have provided me with inspiration. I've met many of them in person over the past half decade or so and these encounters have deepened my pursuit of understanding ever further.

Now that I have a much better understanding of what it is that they taught me, I'm shocked at how poorly this material was often communicated and at how our self-indulgent vanity continues to get in the way of broader communication of ideas that are vital to contemporary society's productivity at a time when productivity is so desperately needed.

I use the term "Egghead" with some affection and admiration, but I also use it in the hopes that some of the great teachers of software development and design will come to learn that they've barely even scratched the surface of the full audience that they need to reach. Eggheads write and speak for other eggheads. The language they chose and the names given to design principles, as well as practices and patterns are stimulating to other eggheads and yet utterly obstructive to the other part of the software development population. When you measure the Egghead population against the mainstream population, the Egghead population doesn't appear to be much more than a rounding error. There's a lot of work to do, and we can do it much better.

Eggheads preach to the choir, and this is often so stimulating that they never leave the echo chamber. They don't learn how to reach the mainstream. They hope that the people they do reach will somehow reach the mainstream, but those people usually end up emulating their egghead heros and become eggheads themselves. The circle expands slightly, but not merely enough to have the meaningful effect on software development productivity that their knowledge and understanding should already have had.

Their communication style is rife with self-stimulating, overly-academic legalese that does little more than enforce an over-estimation of the value of the terminology itself rather than subjugate the terminology to the absolute must of communicating simple and powerful ideas to the mainstream. Eggheads don't like to engage directly with the mainstream. They don't learn to talk to the mainstream and how to teach the mainstream. In this, their self-indulgence leads to terrific loss for human society and is quite possibly one of the most negligent acts perpetrated against the potential for software development productivity.

The divide between the Egghead echo chamber and the mainstream has been readily filled by Shills. While the Eggheads fascinate themselves with themselves, the Shills convince the mainstream to buy snake oil solutions to problems that could be easily solved with plain old soap and water.

The potential for abuse and the leadership vacuum left behind by the Eggheads' self-glorification is readily taken advantage of by Shills willing to convince the mainstream that mere efficiency tools are good solutions for productivity problems. They further exasperate the productivity problems that result from applying efficiency solutions to productivity problems and use the ensuing mainstream customer panic to justify yet more efficiency tools. The mainstream becomes ever more isolated from more meaningful understandings of software development productivity and continues to spin out of control on the back of software systems and software projects that are themselves out of control.

Between the Eggheads and the Shills, things look pretty grim. Those who have good answers to the software crisis are unwilling to forgo the stimulating academic formalism in favor of connecting with the mainstream, and those who would take advantage of ignorance do take advantage of ignorance.

Neither of these two archetypes can be counted on to fix the problem. Eggheads are far too ensconced in the comforts of elitism and Shills have built behemoth networks of companies all selling the same pack of lies, damned lies, and demos. The momentum and justifications of either aren't likely to change anytime soon.

What's needed is a new generation of productivity missionaries who are willing to master the field of knowledge and are willing to learn to connect with the mainstream. They're willing forgo the all-consuming pursuit of elite celebrity and serve society by taking on the software crisis head-on as a matter of honor and duty in the face of continuing negligence and abuse on all sides. They are willing to speak plainly and openly and forgo the perceived legitimization that comes from falling into step with esoteric formalism.

The mainstream has lost track of software development productivity, but it's not so far removed that it can't be recovered. It just can't be recovered through the continued self-indulgence underpinning both the Egghead and the Shill entitlement to ease and winnings in the face of disastrous effects on modern productivity. It can be recovered if pathfinders and communicators are willing to get dirty amongst the "unwashed masses" for an even greater return, and to stand fast against the encroachments of suboptimal local efficiencies bundled with six-figure price tags and promises of yet more software development pain.

Next: Productive by Design

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

Denying Productivity

2010-02-08T01:36:00.011-06:00

(Continued from: Cause and Effect and Developer Productivity)

If you choose to use the ability to control and observe your software to restore and cultivate software development productivity, you have to come to terms with the reality of your software as it presently is, and dispense with the stories you tell yourself about just how much productivity your software development has. It's difficult to accept where you are if where you are is much further back than you had realized. If you don't accept where you are, you won't progress. If you already feel that you've arrived, you won't screw up the courage to challenge what it is that you know, and embark on that next stage of your career voyage.

In the past, we've used the term "testability" to describe the quality of design that allows for the kinds of expectations for software development productivity caused by the ability to control and observe. To those who introduced the term to every day software development vernacular, the term has a very specific meaning, and refers to designs that are very specifically evidenced by a set of well-known and observable design principles and patterns. And to others, the term was misinterpreted and misrepresented as software that is tested.

"Testability" means software that is extremely easy to test rather that software that merely has tests. Any software can be tested, what matters is how incredibly easy it is to do so. The easier it is to test software, the more that the software can be controlled and observed. The more directly that bits of your software can be controlled and observed, the more directly that your software can be understood, and the more that your software design will be simple and clear, and reflect principles productive software design.

The level of simplicity in question is usually beyond the realm of possibility for developers who have not had experience with software that is designed to be quickly and readily understood. When the ability to understand software through the ability to control and observe is understood to be the root cause of software development productivity, the software designs that you create will be radically different than what you may have become accustomed to. And while these designs will seem foreign and strange at first, you'll soon learn to see them as the most natural, workable designs that you've created, and that you've worked with.

For example, there's no doubt that you can control the content of an application's database from the application's user interface, but that is a far cry from a level of control that will have any significant effect on productivity, not to mention that such a means to control and observe doesn't even begin to guarantee the extent to which all the bits of software in between can be immediately understood. It's still control, and it's still control that can followed up by observation, but it isn't direct control and direct observation. If you're concerned with the behavior of your data access logic, for example, you must be able to control it directly by using your data access logic directly rather than using it transitively through an application's user interface. If you must use your application's user interface to observe the results of the control you exert on your application's database, then you're not able to satisfy your concern directly through direct observation, and you're invariably not gaining any of the great productivity benefits that come from productive design.

Be careful of getting ahead of yourself: it doesn't lead to learning of any meaningful significance. Learning to control and observe will bring the biggest advances to your experience of software development productivity. If you stake a claim to this learning before you've barely begun, chances are you'll never really learn what it means and how to use it to any significant degree. And this would be sad, because the means to direct control over your software really isn't difficult to learn. You will be disrupted more by the mass of unlearning of what you already hold firmly as software productivity than by the small amount new learning that you'll really need.

If you want to reach into this realm of productivity that is beyond what you've yet experienced, then commit yourself in earnest to be a student of software design principles. Learn how to apply simple software design principles and exercises to productivity. Commit to a journey to master software design from a principled perspective where productivity is your a-priory concern and the thing that you delivery consistently. You'll find that there's really not a lot to learn once you're over the initial interference of what you presently believe.

It's vital that when you embark on the exploration of the next realm of software development productivity that you start from a realistic place, and resist every urge to claim victory before you've barely out of sight of your own home port. If you stake a claim to understanding what it is to control and observe your software, you'll deny the vast wealth of productivity that is practically within your reach.

It's hard to start down a new path to new understanding, but denying that you need to continue learning and to challenge entrenched orthodoxy is no way to start.

Next: How the Mainstream Lost Software Development Productivity

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

Cause and Effect and Developer Productivity

2010-02-07T21:47:00.005-06:00

(Continued from: Mistaking Efficiency for Productivity)

By mistaking developer efficiency for developer productivity, we end up creating less productivity. It's an easy trap to fall into. The very shape of your organization is an amalgamation of past responses to productivity problems. Efforts to increase productivity that don't penetrate to the depths of the problem but only reach so far as efficiencies localized to particular job functions not only fail to solve productivity problems, they also fail to fix the counter-productive organizational problems that are the unfortunate side effects of previous naive attempts at treating productivity problems to local efficiency solutions. The organizational problems are also contributors to the vicious circle that worsens software development productivity.

Trying to solve productivity problems by chasing efficiencies that are tied to a particular job function and are not coordinated with other job functions is like swimming in quicksand: even though your right hand and your left hand are doing everything right for everything you know about swimming, the swimming motions applied to the actual medium that you're in are just as likely to make you sink. Swimming is the wrong response to being immersed in quicksand. No matter what your panicing mind is telling you to do, it's just grasping at desperate straws of well-established habits rather than assessing this new situation with responses that might be new to you, and thus quite likely less informed by existing habit. Applying the wrong physics to a medium is almost guaranteed to create side effects that defeat the progress you make against the productivity problem you're trying to solve.

The software development productivity problems that you face are due to a productivity balance sheet that fails to tally the losses as well as the gains. If you simply add more gains to the balance sheet without any regard to the losses, you're not going to understand why the bottom line keeps getting smaller while you're continuing to invest ever more energy into the individual parts of your software development effort. It's not enough to get a bigger bucket to bail the water out of a sinking ship if you're not paying any attention whether the that hole letting the water in is bigger than your biggest bucket. Most software productivity efforts end up snatching a fire axe off the wall and desperately trying to hack another hole in the hull to let the rising water out.

If your organization chases local efficiency solutions to productivity problems, it will end up fracturing itself along job functions that are not entirely separate job functions, but rather individual items on job completion checklists for cohesive workgroups or single workers. As your organization adds to the weight of the processes that petition the productivity spirits to unleash more of this mysterious magical substance from whence we know not, it invariably creates more high ceremony work for managers, eventually calcifying them into clerical functionary roles rather than freeing them to be effective and experienced teachers. The increased ceremonial workload leaves your organization devoid of the leaders who ensure that your organization cultivates successive generations of master workers.

The increased management of ceremony makes it seem as if these managers are doing so much work that the organization around the workload deserves to be promoted to its own department. The resulting departmentalization creates even more of the handoffs and coordination problems that are the fuel for the productivity bonfire consuming your project's allowance of money, people, and motivation.

Your organization will tend to become a fractured collection of organizational shards as it spends more and more of its energy dealing with the mounting productivity losses rather than on producing. This kind of organization produces more internal processes than goods and services that it can exchange with customers for money. Worse, it dries up the pool of knowledge, insight, and vision that creates compelling products and attractive, compelling organizations that compete successfully for more good people and that transform their people into the next generation of success makers.

If you're working off of a one-sided balance sheet, you're failing to connect cause and effect. Failing to connect cause and effect is one of the most common behaviors of contemporary software development when it comes to productivity.

The one-sided balance sheet is a glaring genetic marker of software development that has not been able to connect the effects of it's efforts to the causes of impoverished productivity. The more that one-sided, uncoordinated efforts for productivity fracture organizations along unnatural lines, the more difficult it becomes for software development workers to see the causes of their effects, and the more that dramatic under-performance becomes remarkable. This kind of organization has forgotten the vast wealth of productivity that is its birthright.

The real productivity that you should be experiencing is far beyond the level of productivity machinations that are typically entertained today. The greatest drawback to the promise of software development productivity is just how far-fetched the proposition of potential productivity is. It's multiples greater or orders of magnitude greater than what has become common today.

Amidst all the unbelievable claims of missed productivity is an anchor that can hold you fast to reality of high performance software development: the answers to productivity are incredibly simple, incredibly straight-forward, and incredibly easy to put into practice. There's no magic, there's no mysticism. There are just plain old software design principles at the heart of the matter. Principles that, while seemingly named in a fury of self-indulgent academic terminology fetishism, are nonetheless very easy to understand in practice when they are connected to cause and effect in software development productivity. They are simple principles that can be brought into effect in software through even simpler exercises. Deceptively simple exercises, in fact.

But first, cause and effect have to be connected so that the actions and habits that create the detrimental effects are recognized, understood, and curtailed, and the actions and habits that create productivity are practiced, understood, reinforced, and communicated to others.

First things first: the people who create software must be required to prove that the software that they create can quickly and easily be proven to meet the expectations of it. Expectations for just how quickly and easily these proofs can be made will seem daunting at first, as the organizational fracturing that has been allowed to infect software development as a result of one-sided productivity balance sheets has cultivated a generation of software development that has lost touch with the design simplicity that allows software creators to assume the burden of proof of their own work.

The moment that developers are reconnected with the burden of proof of their own work, software development productivity restoration begins in earnest. To restore software development productivity to your organization, you must reclaim the responsibility of the burden of proof for your work. You do this by learning the dead-simple techniques that cultivate the ability to control and observe your software.

In order to provide a proof that your software works, you need to be able to be able to rapidly control and observe your software. This will invariably change the designs that you tend to use, and guide you toward more simple and clear designs that end up being more easily understood by others, which even further improves software development productivity. Software that isn't easily-understood is the single most important subject in software development productivity. The inability to easily and readily understand software at a glance is a huge part of the productivity loss that goes unaccounted in software development management.

Because of the exasperated fracturing of your organization into departments that are not natural reflections of productive software development, and that contribute to the productivity losses on your software development performance balance sheet, you will not have developed a sensitivity to productive designs. That sensitivity will come. It will come with practice. And while you're practicing control and observe techniques, you're breaking down the barriers that keep both your software and your organization from its productive potential.

The moment you assume the burden of proof, you take steps to radically re-shape your software and your organization to a level of sustained productivity that you would not have presumed possible. By learning to control and observe your software ever more effectively you'll naturally close the gap between the cause of productivity and it's effects.

Next: Denying Productivity

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

Mistaking Efficiency for Productivity

2010-02-04T02:24:00.012-06:00

(Continued from: Controlled Productivity)

When productivity starts to decrease and costs start to increase, we tend to panic. In that panic we often accidentally take measures that increase developer efficiency. In the process, we usually end up creating obstructions that decrease productivity.

Productivity that comes from the ability to control and observe is rooted in software design. Specifically, designs that make controlling and observing simple, clear, and very easy.

When productivity starts to fail, you will invariably find software that is difficult to control and observe. You can restore and sustain productivity by exercising controlling and observing. The very act of making your software more controllable will displace less productive designs with more productive designs.

Without connecting the effect of software development productivity to the cause of controlling and observing, you're likely to end up chasing efficiency rather than productivity, and exacerbating the productivity problems you are trying to solve. Most of what we believe about developer productivity has little effect on the ability for developers to control and observe their software. Most efforts for developer productivity end up increasing the pace at which developers create software that is beyond control.

Developer Efficiency

There's a downside to focusing on and increasing the efficiency of code production: it creates a discoordination between the production of code and everything else around it, like testing, operations, planning, and design. If you can increase the pace of not only coding, but also increase the pace of everything after it and before it at the same rate, productivity increases without risking the detrimental side effects of localized efficiency.

Inevitably, increasing the pace of coding without increasing the pace of the whole of software production creates in-process inventory. In-process inventory has even more deleterious effects: It creates rework. The time spent in rework is lost productivity. You're not producing new value when you're busy reworking stuff that is already supposed to be creating value. Decreased productivity creates more panic, and more panic often leads to more ill-fated efforts to rectify the problem by increasing developer efficiency.

If your wheels are spinning in mud, pressing harder on the accelerator doesn't free you from the problem, and it will likely just get you deeper entrenched in the problem. The material ejected from the hole that you're digging collects as in-process inventory. Not only do you not get anywhere, you loose ground.

It's not hard to remain in control of productivity. The trick is to know the difference, to remain calm in the face of panic, and to exercise control and observation until you've got software design under control. And ideally, try not to be distracted by elaborate tools promising productivity if in the end all they offer is a more efficient way to spin your wheels in the mud.

Don't panic. The first decision that comes to your mind when you panic in the face of decreasing productivity can lead to the temptation to displace productivity with efficiency. Don't increase the pace that you're loosing control of your software. Settle in and regain control. You'll restore the productivity you lost and find that there's even more to be had.

Of the developer productivity tools that you have adopted, have they noticeably increased the rate at which your organization makes money as a result? The pace that you can continue turn ideas into money is the definition of productivity that matters. If you focus on the pace that you produce code, you're looking at a part of the picture that is usually too narrow to be meaningfully thought of as productivity.

Next: Cause and Effect and Developer Productivity

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

Controlled Productivity

2010-02-03T21:42:00.014-06:00

(Continued from: To Control and Observe - Productive Software Development)

You can work at a level of productivity that redefines your present expectations by learning how to intentionally control and observe your software. Controlling and observing is something that every developer does. Doing it consciously makes productivity intentional - it brings productivity squarely under your control and conditions you to see ways of creating even more of it.

You can't use what you don't understand. It's as simple as that. The easier it is to understand how your software works, the easier it is to understand the repercussions of making needed changes to it. The easier it is to understand how your software works, the quicker you can get to work on it and the quicker you can get done. Inevitably you understand how your software works by observing it. In order to observe your software, you have to be able to control it.

Controlling your software means putting it into a state where you can directly run the chunk of code that you're concerned with without having to prepare adjacent chunks of code. If those adjacent chunks of code aren't your direct concern, then you should minimize their interference with the observations you're trying to make and with the understanding that you're trying to develop.

In the end, all software is controllable. If you can open one of your application's screens, fill in some text boxes, click on some buttons, and end up saving some data in your database, then you're controlling your database through those screens. The issue isn't that software is or is not controllable, but how easy it is to control it. You don't get productivity from the mere fact that software can be controlled. You get productivity from how software can be controlled. Some ways of controlling software are incredibly productive - beyond most people's expectations.

The more direct control you have over your software, the more productivity you'll have. Direct control means that if you're trying to run some bit of code in order to observe it, that you only have to setup that bit of code and interact with that bit of code. If your software is designed for controlled productivity, you can do this at all levels of your system, from function libraries, to classes, to layers in n-tier and distributed applications, to user interfaces, to deployment systems, to runtime monitoring.

We're so used to primitive productivity in software development and primitive productivity is so common and so prevalent that we've lost track of basic principles that are still available to us if we step outside of the limitations of our current view of software development - a view that has taken up residence in software development only within the last ten or so years.

The principles are also unfortunately named. The names almost complete obscure their meaning, making incredibly simple and incredibly powerful ideas accessible to only a few people who have a natural penchant for deciphering software development legalese.

Designing Productivity

Higher order productivity - productivity beyond what you'd expect would be possible - is only created by software design. That's it. No tool, no matter how elaborate, can ever create the level of productivity that controllable software can (unless you're applying that tool to your work after having made your software easily-controllable and readily-observable).

To make software controllable, you simply design it in a way that you can have direct control over any bite-sized chunk of it so that you can make observations of it with an absolute minimum of effort and minimum of distractions by concerns other than the one in your crosshairs. The means to designing controllable software is also deceptively simple. It's based on utterly and trivially-easy exercises that can be done with any software development tool whether it costs thousands of dollars, or whether it's absolutely free.

There's a simple way to test if your software can easily be controlled and observed: Choose one bit of important logic buried in your software that is only executed when some if/then statement (or other conditional branch) flows execution to that bit of code. See how much code you have to write before you can run that bit of code, and print out its results. If you have to control not only the code that you're concerned with, but also adjacent code, classes, systems, database tables, logins, etc, then your code is more difficult than necessary to control and observe.

You loose productivity as well as motivation as your system becomes more difficult to control. There's another level of productivity available to you. That level of productivity can increase your effectiveness by many multiples, and maybe even by orders of magnitude.

Next: Mistaking Efficiency for Productivity

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

To Control and Observe - Productive Software Development

2010-02-03T15:22:00.011-06:00

There isn't a productive software development effort where controlling and observing aren't the substance of productivity. If you break down productivity to it's most fundamental element, you'll find that the understanding of how your software works is the essence of it all. Control and observe your software and you understand how it works. When you understand it, you can change it, work with it, and continue working with it. When it gets harder to make observations of how your software works, it becomes harder to remain motivated to do the right thing. In the extreme, we live out software projects in survival mode, and we saddle someone else with the responsibility of observing whether our software works. It's not the only way. It's the worst way.

The more that you can make observations about your software, and the more that those observations can be made in thought-sized chunks, the more easily it is to understand your software. To make an observation about your software, you have to be able to control that bit of software to do the thing who's side effects you want to observe. The easier it is to do that, the easier it is to understand it, and the more productivity you have. The time that you spend deciphering software that should be readily understandable is mostly wasted time. It's time spent that shouldn't be necessary and that can be eliminated.

Software that is hard to understand is software that is hard to control. Software that is hard to control is hard to understand. A small bit of code that you want to observe should be controlled with as little code as possible. If you can run that small bit of code directly without having to also control adjacent code, then you've got code that is inherently easy to control, and a level of productivity that is inherently greater. We tend to overlook the amount of time that software teams spend controlling and observing, and when things start to become difficult, we tell ourselves that we can't afford to pay attention to it. Ironically, paying attention to it solves the root problem.

Here are a couple of examples of code that is easy to control:
- In-memory objects that can be observed without loading their data from the database
- User interface workflow that can be observed without using the user interface
- Business logic events that can be observed without the auditing software making recordings
- Steps of complex business processes that can be observed without starting the process from scratch
- Secure operations that can be observed without having to authenticate
- Payment logic that can be observed without connecting to a payment processor

If I'm concerned with the functioning of in-memory objects, and if I need to load those objects from a database, then I have to add the database to the things I need to control, and to be concerned with as well. This isn't a natural, defacto quality of software, regardless of how common it is.

We generally accept that the lack of control as a defacto quality of software projects. We overestimate the control that we have, and we underestimate the value of increased control. We don't pay it much attention. We believe that that the limits to the control that we have is just part of the very fabric of software development, that it's unchangeable, and that there's no reason to dwell on it. We may not even have an awareness of it, or of the issue. This is the fatal flaw in software development thinking, because it's the issue of control that explains why software projects rapidly loose productivity and why the extent of that productivity loss is so great.

Maintaining the ability to control and observe is a conscious, intentional effort. If you're not on top of it all the time, it slips away. The traditional productivity loss curve and the traditional cost curve subsequently begin to immediately express themselves. You can tell yourself it's just the way it is, or you can realize the root cause of the problem and the solution and not only regain that lost productivity, but then go on to achieve a level of productivity that you wouldn't have believed possible from your previous perspective.

This issue isn't unknown. In fact it's well-known. The most common mistake in production management is not paying attention to how productivity loss happens and focus instead on increasing the efficiency of the work that is done amidst the accelerating losses in effectiveness. This mistake is the basis for most software production management at this point of industrial software development.

Next: Controlled Productivity

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

QA Missed Something

2010-02-03T02:00:00.018-06:00

When a team is closing in on a release it may still find a flaw so terrible that the release opportunity might be missed. After the initial panic settles down, we go looking for the explanation of why a such a significant problem can remain hidden until so late. Inevitably, QA missed something.

Let me tell you something: there's nothing that QA has ever missed that developers didn't miss first.

Blaming testers for not discovering flaws that they did not create while simultaneously believing that we don't have to check our own work while is it fresh in our own minds is dishonest. There's no defect ever found by a tester that wasn't first designed and implemented by a developer.

Software is a production industry that generally still believes that the people who make things and the people who prove that those things are right should be different people doing two parts of a single job at different times.

Part of a tester's job is to cross check the work that has already been checked by the workers who create the software and who have the best, timeliest knowledge of it. When a tester isn't cross-checking, he's analyzing and doing exploratory work - looking for possible gaps in developers' thinking, understanding, and observation. When a developer's responsibility to deliver repeatably-checked work is passed over to a tester, neither is effective.

It's less of a tester's job to check that a developers' code is right, but that their tests are right, or at least that the result of the development so far is right - which includes tests that have been written before final inspection. That work doesn't start after the code has been written, it's starts before, as they work together to ensure that by the time the product and the tests make it to the final inspection, that all the ducks are already in a row, leaving the tester with the space to continue to question exactly what it means for the software to be right, and how to perform final inspections that hold up their part of the shared responsibility for intentional quality and productivity.

Final inspection is the last place that you want to find game-changing flaws and problems. It's the last place you should find them. It happens, but it should be the exception to how development is done, including testing, and the exception to how you treat final inspection.

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com