Scott Bellware

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

Analysis: CodePlex Foundation - The Terms of Mutual Surrender

2009-09-11T18:44:00.025-05:00

Microsoft announced the CodePlex Foundation yesterday. The strategy is quite compelling, and frankly, it points to a watershed moment, a turning point for the Microsoft platform and .NET community, as well as for Microsoft.

The CodePlex Foundation initiative translates resoundingly to one great thing: Opportunity.

History

In April of 2001, Microsoft released Beta 1 of the .NET Framework and Visual Studio .NET. At the same time, Jim Newkirk and a couple of industrious .NET early adopters with a track record in agile development in Java released NUnit, an open source unit testing framework for .NET.

Whether NUnit was the first open source application in the .NET ecosystem, who knows? Nonetheless, NUnit was the first open source .NET software for many .NET developers who looked to open source for answers even before .NET itself was released. Jim is presently a CodePlex Foundation advisor and Product Unit Manager for Microsoft's CodePlex open source repository.

To say that the rest is history is a predictable cliche. Whatever has happened in open source in the Microsoft space up until now, as astonishing as many .NET open source accomplishments are, it may pale in the face of the opportunities that are available in light of the CodePlex Foundation initiative.

Of the time between April of 2001 and the present, the following can be said of open source in the Microsoft space: It was a constant battle. Open source was stigmatized. We had to fight to use open source software in our jobs. And when we weren't fighting to use open source, we were fighting to not have to use commercial clones of open source software that often weren't nearly as robust as the open source.

Certainly things have been getting better in the past few years. More organizations have opened up to open source - especially when open source solutions are the best-of-breed - but Microsoft's own lingering reticence toward open source remained the elephant in the room, and a significant influence over the customer community's perception of open source.

And even though Microsoft has been making some inroads into open source over the past few years, Microsoft's own open source has remained constrained. With a couple of exceptions, Microsoft did not accept contributions to its open source from contributors outside of Microsoft. And Microsoft developers were discouraged from or disallowed reviewing open source code for fear of infecting Microsoft products with potential "viral" effects of some open source licenses.

Imitation is the Sincerest Form

In the past eight years, Microsoft has learned a lot from open source software. A number of Microsoft product ideas were proven first by open source projects. However, because Microsoft itself has not been open to open source solutions, and because a good bit of Microsoft's customer community follows Microsoft's lead on many fronts, the only way that Microsoft could provide its customers with the value available to open source users was to develop new products from scratch.

Microsoft's efforts at duplicating the value offered by open source were fraught with problems. Microsoft employees can't look at the open source code, so Microsoft's competing offerings weren't often too terribly competitive. They would be adopted by Microsoft customers nonetheless on the basis of Microsoft's merit as the largest commercial software foundry.

All this leads to an oft-repeated heart-breaking scenario for .NET developers who are already well-versed in best-of-breed .NET solutions that have matured in the open source world: showing up for work one day to learn that the company you work for has chosen to go with an immature, inferior solution that Microsoft had been left with little commercial choice but to build. This sinking feeling is followed up quickly with the realization that a company the size of Microsoft can't release innovations and fixes as fast as an open source project. The Microsoft clones of open source projects progress slowly while the open source solutions drive ahead with innovative and often more productive solutions.

Ultimately, this cycle repeated year after year and often created an ever-deepening insularism in Microsoft that exasperated the problem even further.

Opportunity

The CodePlex Foundation will bring influential open source projects under its auspices. The details aren't clear yet, but it's reasonable to assume that the foundation will support its projects the way that other software foundations support their projects, with protection for these projects as they are used in corporate and commercial contexts and who knows, maybe even some financial support will be part of the deal.

The single greatest opportunity that the CodePlex Foundation represents is an end to orthodox resistance to open source by Microsoft, and its customer community by extension, and the dawn of a new day of .NET where open source can be openly embraced.

In a potential tomorrow, the best tools for the job aren't sources for intellectual property suspicion, talented software craftspeople have greater freedom to use the tools that they have built significant mastery of, methodologies and techniques aren't driven by tool limitations, and innovation is free to move it its own pace, and can do so as a cooperation between industry and community.

And most importantly, in a world where Microsoft begins to embrace open source, it begins to subject itself to the open competitive forces that will make its products better, and make Microsoft itself a leaner, more agile company.

In this world, .NET open source champions aren't relegated to a relatively small backwoods, but are granted the broad regard and respect that is common place in the Java, Ruby, Python, and PHP worlds, among others with rich open source culture and history.

Also consider that in this world, we're one-step closer to the level of comfort with open source for Microsoft where community contributions to Microsoft's MSPL projects can be possible. The arrival of the CodePlex Foundation doesn't provide for this, but it does provide for the next few significant steps on the way.

This effort will bring Microsoft staff into close encounters with open source software and open source software projects, breaking down the barriers that the community has descried for a long, frustrating time.

I understand that in concert with this effort, Microsoft is also changing its policy for open source contributions for its staff, allowing staff to make limited contributions to open source without the requirement of oversight from Microsoft legal staff! This is a significant shift in policy for Microsoft and points to some significant reconsideration of policies and philosophies of the past.

What Price Freedom?

The source of Microsoft's trepidation over open source hasn't changed. The central issue is still, and will remain for the foreseeable future, intellectual property risk. The source of the trepidation for many of Microsoft's customers remains intellectual property risk.

The solution to the problem is as obvious as it is genius, but the price of freedom isn't without some non-trivial compromise, and a challenging new paradigm for open source leaders to consider.

The intellectual property risks can be greatly (if not entirely) mitigated when intellectual property is assigned to an intermediary, and that, among other services, is what the CodePlex Foundation is for.

Put frankly and directly, the CodePlex Foundation is given ownership of the code.

Per the CodePlex Foundation Assignment Agreement:

"Assignor assigns to Foundation its entire right, title, and interest in any copyright rights that attach to the Code and any documentation delivered with the Code."

Per the terms of the agreement, the Foundation grants an irrevocable license to the code to the original owner. Again, from the CodePlex Foundation Assignment Agreement:

"Foundation grants Assignor and its affiliates a perpetual, worldwide, non-exclusive, royalty free, irrevocable license, to reproduce, modify, create derivative works of, display, publicly perform, sublicense and distribute the Code (and derivative works thereof) as Assignor or its affiliates see fit, including the right for Assignor and its affiliates to sublicense the foregoing rights to third parties."

Ultimately, this means that it's business as usual for the open source projects, with the additions of the protections of the CodePlex Foundation, and greater opportunity for project adoption in spaces that were not previously open, and the chance to participate in what might be a more cohesive and cooperative open source community at large in the Microsoft space.

The Inevitable Distrust

There's no avoiding the issues of distrust that will surface from this. The usual suspicion is inevitable considering the history of Microsoft and open source, the invitation to open source projects to give ownership of their code to the CodePlex Foundation, the preponderance of Microsoft staff on the foundation's interim Board of Directors and Board of Advisors, and the branding of the foundation with an existing Microsoft brand: CodePlex (also the name of Microsoft's public open source repository and community site).

Microsoft has a habit of springing things on the community. But then, so does Apple, and so does Google. Love it or hate it, this is how product companies launch products and how they protect themselves. It doesn't always work out so well, and for my money, Microsoft is the least best of these companies when it comes to operating without early and continual customer feedback in product development, but, well, there you have it. That said, the CodePlex Foundation isn't exactly fully operational yet, and for all intents and purposes, this is the opportunity that the CodePlex Foundation has provided for community input, and the foundation staff has gone out of its way to make this point clear on the foundation's website.

The easiest way to staff up the foundation is to do what Microsoft did. It tapped the people who worked to make the CodePlex Foundation happen for interim positions in the leadership of the foundation. It also assigned some serious business acumen to the interim Board of Directors. Having Microsoft staff in-play on the Board of Directors is just a smart, immediately-sustainable thing for Microsoft to have done with the investment that has been set in motion. The Microsoft staff on the Board of Advisors include many people who are friendly to open source and who are personal friends of many people in the open source community.

And there are a few key names that should likely be on that list. Ayende Rahien and Jeremy Miller immediately come to mind - people who have brought a number of influential open source projects to life, and help to bring those projects into enterprises and ISV's around the world. But this thing is just getting started. It's a "soft launch", as one of the members of the Board of Advisors put it.

So why would Microsoft collude the namespace by naming this fledgling foundation after its CodePlex program? Sure, they're both about open source, and sure there's a healthy dose of Microsoft in the mix, but why not make the effort to disambiguate right off the bat?

John Peterson, a veteran software developer, former Microsoft MVP award winner, and attorney, has been helping me to understand the CodePlex Foundation agreements, and I like his take on the CodePlex naming, and why it's a good idea.

Microsoft has donated one million dollars to the foundation to get it up and running. It has an accountability to its stockholders for what it does with its cash. And while one million dollars might not seem to be much compared to Microsoft's bank balance, it's not exactly a trivial amount when it comes to charitable contributions to what appears to be a fairly radical cause.

The perpetuation of the CodePlex brand is just a good investment, and it likely helps this kind of move go down easier with folks in Microsoft's stockholder community who might not entirely understand what this open source kerfuffle is all about. Microsoft is making this thing happen. It's reasonable that it gets to pick the name, and to use a name that highlights other aspects of its open source efforts.

The Windup

I'm not usually the first person to extend unquestioning trust to Microsoft, and I started my day yesterday with the inevitable distrust and backlash, but I think there's something much more significant here that deserves more than just the usual distrust, and might likely be better served with an unusual trust.

Imagine for a moment if this effort had happened five years ago. Think of all of the often-frustrating pieces of the Microsoft stack that we've had to deal with - software influenced by open source, but missing the target because of Microsoft's policies on staff exposure to intellectual property risks - real or imagined.

Think of all the tools and all the libraries that have shipped from Microsoft over the past five years where your response was a despondent, "Oh no, not again." Part of the reason why we have to contend with these tools is that Microsoft, up until now, has not been able to truly learn from the many mature systems from the open source world that it is called to address with offerings of its own that cary Microsoft's implicit protection from intellectual property risks.

Microsoft isn't going to simply change its well-healed habits on a dime, but we're at a moment where turning in the right direction will set in motion the chain of events that will ultimately change Microsoft's culture in regards to it's ability to see, to leverage, and to participate in some of the incredible work that is being done outside of Microsoft's walls.

The Pitch

I'm hoping that the influential open source folks in the .NET community will consider the CodePlex Foundation's invitation, as odd as it may seem, to consider the possibilities for a future where the .NET community at large has the same common sense perspective on open source as the Java community, the Ruby community, and all of the other communities who's no-nonsense perspective on open source we often covet.

Sure there are lots of details to be ironed out with the CodePlex Foundation program, and the next few weeks will be telling in that regard, but it's with the participation of the open source community that the changes that we've been talking about for years can finally get underway.

I don't own an open source project that I've invested years of my life into, but I can guess what it must feel like to have it suggested that ownership of such a project be handed over to a foundation, and a foundation with very close ties to Microsoft at that. The open source community is being asked to meet the resistance half-way, and to hammer out a program that history will recognize as the turning point for Microsoft, it's customers, and almost every aspect of Microsoft community, culture, and product development.

If you're an open source project owner, think of the possibilities of having your framework or your product begin to reshape the expectations for craftsmanship of Microsoft staff and the greater Microsoft community at large. No one is in a position to require an open source leader to assign their copyright to an intermediary, but the first few influential open source leaders who do meet the CodePlex Foundation halfway will set in motion the kinds of pervasive, positive changes that will change all of our lives and careers for the better.

It's a relationship that starts with one hell of a compromise, but it could be the beginning of a beautiful relationship. Possibly even a historic one.

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

Do Agilists Understand Lean?

2009-07-19T18:53:00.006-05:00

One of my previous bosses, Steven "Doc" List used to tell me that I'm at my best when I'm teaching. Sometimes, Doc's compliment would strike a raw nerve. Programmers on our team were entitled to choose whether on not to learn. This wasn't an explicit policy, but was engrained in our culture.

We valued learned people, but learning and teaching was not part of our culture or our organizational mechanics. We valued ready-made learning when it walked through the door, but our organizational learning didn't go further than the Agile Retrospectives materials and practice that was fashionable at the time. That's no fault of Agile Retrospectives per se. It's a fault of turning it into something fashionable, and inevitably conferring the unconscious orthodoxy onto it that was steadily growing in Agile methodology culture, often obstructing the line of site to the need for a higher order of teaching, learning, and management culture.

Unless team members understand that there is a requirement to be students in an organization, and to study under a teacher, pride and prejudice will likely obstruct the acceptance of a formal student/teacher relationship, and attempts at teaching will very likely devolve into the predictable butting of alpha geek heads over design and process ideas. And this portends obstructions to meaningful and methodical continuous improvement driven by program goals, and a rise of wild, uncontrolled experimentation.

In his book "Managing to Learn: Using the A3 Management Process to Solve Problems, Gain Agreement, Mentor, and Lead", John Shook tells the story of a manager who's supervisor once told him, "If the learner hasn't learned, then the teacher hasn't taught".

I used to tell Doc that it is painfully frustrating to teach knowing that our staff understood that they were not required either by culture or by supporting policy to be in the role of learner - especially when program and project expectations were not being met.

It's true that if the learner hasn't learned, then the teacher hasn't taught. It's also true that if the learner doesn't show up, then the teaching doesn't even begin.

Leaders at successful Lean organizations have pointed out that companies who have failed to duplicate Lean successes often do so by trying to adopt Lean as a process improvement effort rather than an effort to create a learning organization. Despite all of the interesting and beneficial mechanical aspects of Lean, Lean is about creating learning organizations. Student/teacher relationships and protocols are a part of learning organizations, with each role having the responsibilities of that role.

There has been a bit of a dust-up in the agile community lately as to whether Kanban work management is necessarily non-agile or anti-agile. The premise being that Kanban can foster environments of directed work, limiting workers' ability to self-organize, and fostering a disrespectful environment for workers as compared to forms of work management and organization common to agile methodologies.

The essential issue here is the issue of respect, but I find that the Agile perspective is willing to take advantage of incomplete and opportunistic definitions of respect. Kanban proponents have rightly pointed out that respect for people is an explicit Lean principle, and that self-organized work is still happening within Kanban workflows.

I see two perspectives talking past each other, and unfortunately, I see Kanban practitioners being backed into a corner, retreating, apologizing for Kanban, and softening the message to make it more palatable by the dominant methodology culture. Ironically, this was the exact position that the Agile was in at the start of the decade when Agile was struggling to make headway against prejudice and misrepresentation by the preceding traditional methodology culture.

Agilists are concerned about returning to the bad old days when disconnected managers directed work from outside the context of doing that work. It's a serious issue that deserves serious concern. It's a serious enough issue that it demands rigor on the part of the mainstream Agile community to engage the effort to understand Lean more deeply than the often cursory glances and biases projected at Lean and Kanban.

I sympathize entirely with the concern of returning to the bad old days of pre-Agile bureaucracy, but I'm equally concerned about the same tendency for Agile bureaucracy to occlude the meaning of Lean and Kanban.

My study of Agile began in 2000 when a mentor from Bell SIGMA turned me on to XP. My day-to-day immersion began in early 2001. I don't want to return to the bad old days either, but I don't want to go forward into a revised, 21st-century kind of bad old days issuing from the same mechanisms of bias and presumption that Agile itself faced, and often continues to face.

I wonder if agilists at large, in the spirit of inspection and adaption, are taking the time to understand Lean and the organizational and cultural context where Kanban thrives. With Agile, we asked organizations and cultures to consider change. I wonder now if Agile is able to respond to the same challenge.

On the surface, the following statement should rile a mainstream agilist. At least, it certainly used to rile me. It riled me enough not to act upon it even when my instincts told me that it might make a world of difference between immanent failure and rescuing a project, its team, and a considerable investment.

It's perfectly acceptable for a manager to direct the team from a position of traditional, hierarchical, directive authority.

I'm taking egregious advantage here in setting this stage. I'm purposefully leaving out the implicit context inherent in Lean. If I looked at the preceding statement through Agile's lens, I might very likely be worried about it. Looking at the statement through Lean's lens, I'm perfectly comfortable with it.

If we don't look at Kanban through Lean's lens, we're committing the anthropological cardinal sin in failing to realize that we're projecting cultural bias on what we're observing. We're even failing to recognize that Lean may have culture and behavior that is based on different assumptions and biases.

Kanban isn't a return to the bad old days of disconnected, directive authority because the position of management in-situ in a Lean organization isn't the same position of management that Agile efforts are commonly called to contend with and the behavior of management that many of Agile's protocols are shaped to deal with.

A manager of a Lean software development team isn't a remote figure who is no longer in the game. The manager is on the team, and he's one of the most competent technologists on the team. The manager in a Lean organization is also a teacher.

A team that includes a manager with directive authority is still self-organizing. The manager is internal to the team. A manager's expectations aren't disconnected from the reality of the work. And when those expectations aren't being met, he can chose to use directive authority to guide the team to counter-measures through teaching. It's also the manager's duty to help people on the team to develop critical thinking skills and instincts that serve problem recognition and resolution in support of the goal.

The expectation for team members to fulfill their duty as students is part of the managers directive authority. Refusal to engage in the protocols of the learning organization is deeply disrespectful to the organization of people as a whole, and to the manager as a person.

Looking at Lean through Agile's lens is perfectly reasonable. It gives a comparative perspective that can help us understand differences and find meaning. But ultimately, Lean should be seen through Lean's lens and should be assessed from the perspective of its native context.

There is a greater issue of respect and disrespect that is inherent in Lean as seen through the Lean lens. Respect is a two-way street. There is the respect for workers and the respect for managers, or teachers. The mutuality of respect is what makes respect possible. When respect ceases to be mutual, it ceases to be sustainable, and will soon disintegrate.

One of the most intractable issues we have in software development cultures is the lack of line management that remains technically-competent. In fact, line managers in software development are often people who choose to escape to management when they discover that they don't like making software.

We're presently dealing with the effects of several generations of software managers who don't really have much of an idea of what software development work is in detail, which means that these managers can't be effective teachers. Workers don't end up with the teaching that makes them effective and makes the work rewarding. The cycle perpetuates itself.

Agile has been a powerful palliative in dealing with this organizational and cultural snag. By putting a firewall between the deleterious effects of directive authority that is too far from the work and the work itself, agile succeeds in restarting the failing heartbeat of getting software made.

In the software industry, Lean is seen as a kind of specialization of Agile, and that's a unique thing for Lean in industry in general. It's also possibly a detriment and maybe even a disadvantage.

Agile is increasingly encumbered by its own presumptions of organization and culture. Agile's biases are slowly fading into background consciousness, becoming unconscious. As Lean is inevitably and unconsciously seen through the lens of colloquial Agile, many of the organizational assumptions and biases of Agile are projected onto Lean without even realizing that these biases are there.

Lean in its essence is a path to critical thinking, but not a solo path. It's a directed path. A Lean organization is a learning organization. It has teachers, students, curricula, and protocols all focused on meeting the expectations that support the organization's holistic goals for productivity and producing.

Lean is a means to find the unasked question. There appears to be an unasked question in the Agile perspective of Kanban and respect: Do we expect that a Lean organization is the same as an Agile organization?

This isn't meant to be a condemnation of Agile, but it is meant to point out that if Agile isn't careful, it will become the same kind of problem that it sought to solve.

On my project with Doc, I was valued as a teacher. I was the person who got executive support for the project. I shared product design responsibilities with our product owner. I would go to bat for the team when hard decisions needed to be advocated to the executive. I did the technical screening of candidates and made my recommendations to the team about hiring. And I was responsible for setting program goals and expectations for technical implementation.

In the end, I parted ways with the team when it became clear to me that the team had become intractably self-determining, which is a potential risk in self-organizing teams when technical competence and directive authority are not invested in the same person. Ultimately, the team failed, a non-trivial percentage of our small company revenue invested in the project was written off, and the entire team was dismissed.

This isn't a typical Agile scenario, but it is very much a possibility faced by teams in situations similar to ours. The failure likely points less to an implicit weakness in Agile and more to an explicit strength in Lean: respect is indeed a cornerstone of success, but if respect isn't holistic, it risks introducing the opportunism that can see to the failure of otherwise meaningful 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

Lean Reading List

2009-07-17T03:10:00.010-05:00

I read Mary and Tom Poppendieck's first book on Lean Software Development, "Lean Software Development: An Agile Toolkit" in 2005. It went in one eye and out the other.

I was the Software Development track chair for Austin's InnoTech conference in November of that year. Mary was gracious enough to accept our invitation to come to Austin to keynote the track and to moderate a panel.

I listened to Mary's talk and got a few more clarifying tid bits from it, but mostly, I dismissed it at the time as some form agile sideshow that didn't quite measure up to the specifics that XP brought to the table. A number of us went out for burgers with Mary after the conference and continued the conversation, but I don't think anyone in the group was fundamentally moved by Lean.

I wasn't equipped with the experience to see Lean for what it was. Later, I realized the deep hubris that encumbered my thinking and the vanity that would lead me to expect that I could intuit a subject as vast as Lean from a single book, the way I could with XP and Scrum.

I suffered a serious set-back in 2007. My career's pinnacle dream project was flirting with disaster.

The company I worked for faced an intractable intellectual property constraint that limited our product's market to a small fraction of the whole. In November of 2006, I sold the company on an ambitious plan to solve the problem by building our own platform that we would have unlimited rights to sell. We started exploratory work and envisioning in December. The undertaking had significant executive sponsorship. When our board of directors voted to not fund the project, the CEO bought out the board and gave us the green light. We started official work in earnest in January.

In November of 2007, I sounded the failure warning alarm to my management, and I kept sounding it. In January of 2008, with the situation becoming increasingly intractable, I parted ways with the project and the company. Three months later, after having given the team a chance to pull itself together, the project was canceled and the team was dismissed from the company - from the most junior technologist, up to the executive overseeing the project.

I was frustrated by having felt handcuffed by Agile development orthodoxies that no longer fit the problems of the team, and yet were followed mechanically, and reinforced by management that was captivated by its first exposure to Agile.

I told some of the details of my experiences to a friend. We talked about Agile, in many variants, including Lean Software Development. My friend recommended that I read about the Theory of Constraints and recommended "The Goal: A Process of Ongoing Improvement" by Eliyahu Goldratt and Jeff Cox. In reading The Goal, I recognized the detailed mechanical process that I faced in the failed project. At that time, I hadn't connected what I had begin to learn in The Goal with what I know about Agile Development and the gaps in Agile that I had begun to see after seven years of immersion.

Following The Goal, I wanted to read more into some of Lean's roots. I had largely avoided the Toyota literature up till that point, and I wasn't convinced that I would get much from The Toyota Production System. I knew a number of people in my community who had read The Machine that Changed the World and The Toyota Production System, but I never really got the sense that the reading had connected them with the transformative learning that I had experienced in Agile development.

Before committing to throwing myself into the Toyota literature, I wanted a sample of what I might be getting into. I started with an article. I read "Decoding the DNA of the Toyota Production System" by Steven J. Spear and H. Kent Bowen published in the Harvard Business Review.

In this article, the authors talk about the things that companies seemed to miss when trying to duplicate Toyota's successes using Toyota's methods. I'm a sucker for stories of unasked questions. The rest of my reading about Toyota and Lean in general would be an exploration of the unasked question. The authors' message: Toyota's fundamental nature as a learning organization is often overlooked, with undue attention paid to Toyota's more obvious practices and mechanics.

And this is what drew me in to the Toyota literature. Here I saw the parallels to my failed organization, my own nature as a learner, a seeker, a pathfinder, and a teacher. I recognized the many of the intractable problems that I had observed in the behavior of my failed organization.

On my team, it had become an unspoken entitlement conferred that people were not required to take direction. This was largely exasperated by a management approach that was fixated on social experimentation and which was not capable of guiding the technical execution or product design imperatives of the project. It was an Agile methods laboratory that produced no real acceptable features for a year.

I learned in Spear's and Bowen's article that the organizational structure, mechanics, and protocols that I felt would benefit the team were the basis of Toyota's organization and culture as I was coming to understand them.

The Toyota Way by Jeffrey Liker was my first read into the Toyota literature. I chose this book to specifically continue learning about the Toyota DNA rather than dig into Toyota's specific process mechanics. Understanding that focusing on the process mechanics led to common problems in learning and adopting Toyota's methods, I wanted to hold off on the obvious aspects longer.

I read the Toyota Way with the observations of the Harvard Business Review article fresh in mind, as well as the mind-opening lessons about work management and problem solving from The Goal providing a backdrop.

Cautious of becoming yet another Toyota disciple, I took a turn away from Toyota-specific literature and back toward Lean in general and read "Lean Thinking: Banish Waste and Create Wealth in Your Corporation" by James P. Womack and Daniel T. Jones. This book tells the story of the companies and people taught by Womack and Jones as they traveled around the world after writing The Machine that Changed the World. It reinforced and what I had learned about learning culture and continuous improvement as well as organizational structure and process in the books that preceded it.

While this reading and studying was happening, I was also tweeting about my experiences and studies, and having numerous long conversations on the phone with some of my peers who had themselves started studying the same material. I also revisited my failed project with the previous product owner, who was still with the company, and still succeeding in his own work.

If I had read this material in a vacuum, without any of the constant interaction with my professional network, and the continual revisitation of previous failure, I believe it would have been a much less informative and transformative experience. My circle of friends and network of colleagues continues to inform my learning, and I expect that it will continue to do so.

I turned the reading back to software, choosing to read Mary and Tom Poppendieck's second book, "Implementing Lean Software Development: From Concept to Cash". Reading a Lean software book from my vantage at that time was a very different experience than when I had read the first Lean software book. The subject had now come to life. It was tangible, and it was deeper than what I had presumed previously. From here, my perspective of Lean Software Development takes meaning beyond my perspective of XP and Agile culture and mechanics.

I had organized the ALT.NET Open Space Conference the previous year, and hadn't want to simply fall into the trap of trying to duplicate an original moment. I wanted another theme for the second annual conference. Over the course of many of those conversations with friends and colleagues, we talked about the essential force of the ALT.NET movement as something akin to Lean's Continuous Improvement. The theme of the second conference became Continuous Improvement, with hopes that we would come to understand it more, and maybe understand better whether ALT.NET is indeed a Continuous Improvement culture.

I subsequently read another Toyota book, "Extreme Toyota: Radical Contradictions That Drive Success at the World's Best Manufacturer" by Emi Osono, Norihiko Shimizu, Hirotaka Takeuchi. This book takes on seeming contradictions in Toyota's culture and organization, such as the simultaneity of both a flat organization and a rigid hierarchical organization and the imperatives of a learning culture and continuous improvement that unify the two. The book also spoke about the climate of contradiction that Toyota uses to stimulate creativity and problem solving.

Tom and Mary accepted our invitation to come to the Continuous Improvement Conference in Austin and share their experience with learning organizations, software development, product development, scientific method, and leadership. I can't imagine that Mary and Tom got as much out of the experience as we did, but they had a lasting impact on our community.

Mary and Tom often say that Lean Software Development is informed more by the Toyota Product Development System than the Toyota Production System. Dave Laribee got to the Toyota Product Development book before I did and warned me that it was quite dry but worth reading, and it was. "The Toyota Product Development System: Integrating People, Process And Technology" by James M. Morgan and Jeffery K. Liker spoke a great deal more about requirements, design, planning for work, and creating workspaces, as well as the risk-mitigation processes that Toyota uses. This book also goes into greater detail about the Toyota's people and roles, and fostering "towering technical competence".

The TPDS book also talks about Lean leadership and the Chief Engineer role. It further reinforces the notion of managers and group leaders as having great technical competence, often knowing the work of their staff better than they do, and being paramountly responsible for teaching their staff though the scientific method and Toyota's A3 report technique.

Dave read David Anderson's book, "Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results" while I was reading the TPDS book, and I followed the TPDS book with David Anderson's book. I wish I would have read this book years ago, but again my biases obstructed my perception of the value I would get from it. In this book, David Anderson ties the Theory of Constraints directly to software development and translates pull systems and throughput accounting to the work.

Dave turned me on to Cory Ladas' writing on the Lean Software Engineering blog. I read a few articles, and then went back to the start of the blog and read forward. Much of that writing has been compiled into his book "Scrumban - Essays on Kanban Systems for Lean Software Development". Cory’s writing goes quite deep into pull systems and Kanban for software development. This material and David Anderson’s book offer a profound exploration of applying the mechanical aspects of Lean.

I put into practice what I learned both from my own experience and from studying and study groups on a project with a distributed team in Austin starting in August 2008. My instinct at first was to overlay their existing organization and process with Scrum. Instead, I looked for signs of what was keeping the organization back, established some basic measurements, and did my best to teach what I knew about how to solve these problems. It wasn't trivial work, but it reaffirmed my experience and study of both the cultural and behavioral aspects of Lean, as well as the mechanics, such as Kanban. The experience also continued to reaffirm XP practices as the tactical foundation of both Lean and Agile strategies.

While in Austin, Mary and Tom mentioned the book "Managing to Learn: Using the A3 Management Process to Solve Problems, Gain Agreement, Mentor, and Lead" by John Shook, which tells the story of the techniques and processes used in learning culture and learning organization, and goes much deeper into the the teacher/student relationship and responsibilities that are the foundation of Lean.

I'm presently reading this book. It's an innovative book not only for its content but also for its form, and is well worth the read, and practice.

Context

I wrote this article because people in my network asked me for some recommendations on books on Lean. The more I thought about it, the more I thought that listing some titles and links might not be entirely responsible.

The books that I read and the order in which I read them is inseparable from the context in which I read them. This isn't a canonical list and it shouldn't be treated that way. There are many, many more resources available.

I've benefited tremendously from the choices I've made for study and for engaging community to enliven that study. I wholeheartedly recommend the books I've talked about here, and I would even recommend going through them in the order that I read them. In retrospect, the reading order worked well as an evolutionary thread and helped me reinforce a deeper understanding of subtler aspects of Lean while continuing to layer on ever broader knowledge.

Nonetheless, your mileage may vary, and if your experiences are quite different from those I've laid out here, then you might disregard my own learning adventure and concoct your own.

Either way, foster a community to learn with, and sit at the feet of as many masters who'll tolerate your presence. Anything you learn from a book is just material until you light it up with experience (or reflection) and turn it into knowledge. Learning in isolation rarely has the yield of learning enlivened by experience and community. That's not always the case, but if you have a tendency to hide in a cave, understand that much of Lean is a social practice.

I still haven't read The Machine that Changed the World or The Toyota production System. I may read them at some point, but my goal isn't to consume every Toyota book that I can find. My goal is to synthesize as much understanding as I can, and the past two years have been very rewarding in this regard.

I recently founded the Lean Software Austin group, and I'm looking forward to continuing the study and the work in Lean principles and software development as this community grows as a learning organization itself. The story doesn't end here, but the narrative reading list does (for now).

For your convenience, here is an actual list of the reading I referenced in this article:

Lean Software Development, "Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck
The Goal: A Process of Ongoing Improvement by Eliyahu Goldratt and Jeff Cox
Decoding the DNA of the Toyota Production System by Steven J. Spear and H. Kent Bowen (Harvard Business Review)
The Toyota Way by Jeffrey Liker
Lean Thinking: Banish Waste and Create Wealth in Your Corporation by James P. Womack and Daniel T. Jones
Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck
Extreme Toyota: Radical Contradictions That Drive Success at the World's Best Manufacturer by Emi Osono, Norihiko Shimizu, Hirotaka Takeuchi
The Toyota Product Development System: Integrating People, Process And Technology by James M. Morgan and Jeffery K. Liker
Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results by David Anderson
Lean Software Engineering by Cory Ladas
Scrumban - Essays on Kanban Systems for Lean Software Development by Cory Ladas
Managing to Learn: Using the A3 Management Process to Solve Problems, Gain Agreement, Mentor, and Lead by John Shook

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 Developer Productivity

2009-07-12T00:43:00.002-05:00

There are a couple of predictable approaches to an imminent car crash. You could throw your hands in the air, scream, and hope for the best, or you could keep your hands right where they are and try to pilot your way through it to the last responsible moment. If you're the pilot of a software team, offloading the responsibility for productivity is like taking your hands off the wheel before you've left your driveway.

The quickest way to shut the door to productivity is to try to solve it exclusively as a tools and automation problem with tools that promise "Developer Productivity". Tools and automation are essential parts of getting software done, but unless you have a firm grip on why you have productivity problems, taking someone else's word for why a tool or automation will solve your problems amounts to little more than a shot in the dark. And since my word is inevitably "someone else's word", please look more deeply into the issue beyond this article.

Productivity that Matters

There's productivity that matters and productivity that doesn't matter. That probably seems nonsensical - after all, if you could gain productivity, wouldn't it matter? It depends on wether the productivity you gain causes a commensurate obstruction at some other point in your software development bucket brigade.

One heck of a lot of tools that are sold specifically as "Developer Productivity" tools create productivity increases for the developers in your development pipeline, and kill productivity for downstream work centers, like testing, packaging, shipping, installation, configuration, and operations.

Focusing on developer productivity without considering the effects of developer productivity efforts on the rest of the whole pipeline will usually create momentary productivity; productivity that only developers will feel, and often only for a short period of unsustainable time.

Software teams and organizations continue to fail to realize sustainable productivity by continuing to make improvements in one area of the pipeline without realizing the cause-and-effect relationship between the localized improvements and resulting degradations in other parts of the pipeline.

Sustainable productivity is the only productivity that matters, and it's the only productivity that can withstand ever more continuous improvements.

Productivity is about product. It's the activity quality of product, or producing, or production - the "ivity" of product. It's about producing and the production of the only thing that really matters - the final product that can be used to achieve the business's goals.

If the goal of software development is just to create developer artifacts without ever delivering them, then developer productivity itself in isolation would matter a whole lot more. The problem with "developer productivity" is that it is inherently productivity in isolation. Productivity in isolation is often naive local optima.

Local Optima

Local optima problems happen all the time in software organizations. They happen when we try to make improvements in one area of the whole software development workflow without understanding the effects on other areas of the workflow.

Developer productivity as we know it colloquially is inherently a local optima concern. My first concern is the productivity of the entire fire brigade. The moment that there's some obstruction anywhere in the whole workflow, the problem will spread outward and poison adjacent work centers, rippling outward, and sometimes making quantum leaps into parts of the pipeline that are, on the surface, seemingly disconnected.

It's not enough to just understand that a change in one area of team's workflow will have effects on another area, it's also critical to understand which kinds of effects will create obstructions for the whole effort.

Greater productivity often come less from increasing the speed that we can do the work itself, and more from recognizing and decreasing the obstructions to production and producing. One of the most obvious ways to attack the productivity problem is to reduce rework and the things that lead to it.

Reducing rework means undertaking organizational and cultural changes. It means that the making of software and the proving that it's right can't be allowed to work at dramatically different paces, which is usually the case with most software teams (even teams using Agile methods).

Every time that testers get backed up in their work, untested software piles up in front of testing. That pile of untested software is the unproven foundation that developers will continue to build upon wether or not it’s sound. As the pile grows, the likelihood of rework grows geometrically, proportionate to the size of the pile, and the near certainty that structural design is insufficiently precise grows along with it.

When the making of software and the testing are disconnected from each other, and software makers and software testers work at full speed regardless of whether they're building up piles of risky inventory, then productivity is going to degrade.

In this kind of situation, doing things that increase programmers' speed isn't going to help productivity at all. In fact, the right thing to do is to either slow the programmers down until the testing inventory is cleared, or to have the developers change hats and work with testing to clear the obstruction. Increasing a developer's speed will only exasperate the problem.

Optimized developer productivity without simultaneously optimizing the entire pipeline is local optima.

Developer Productivity Myths

There are a number of tools and libraries that are sold under the "Developer Productivity" banner. These tools actually deliver developer efficiency rather than developer productivity.

Unless a tool's productivity proposition takes local optima into account, it flirts with negligence. If it does so knowingly and willfully, then it flirts with corruption; verily stealing value from its users and customers.

Consider Microsoft's re-interpretations of "Rapid Application Development" that drive its developer tools design:

Microsoft's Visual Studio enables developers to create input forms and data processing visually with little expense of time and effort. Developers get this work done very quickly, but the resulting systems features are inordinately difficult to test. Microsoft also packages tools that are specifically geared for "testers" in a separate product package, perpetuating the conclusion that doing work and proving that the work is right is the jobs of different people, creating the handoff boundaries that invite unproven work to collect as piles of costly inventory.

While this allows developers to be very efficient in the work of creating the code and artifacts that go into a feature, that efficiency isn’t realized as productivity. The software designs created by developer efficiency tools are unnecessarily and excessively difficult to test. This discourages developers from preventing the defects that pile up in front of the testing work center which also steals productivity from testers, exacerbating the problem of basing today's work on last week's unproven decisions.

Software organizations who are seeking and realizing higher productivity - that is, they produce end product to business sustainably and timely - come to understand that the inventories built up around handoffs and segregated work centers must be decreased and ultimately eliminated in order to really reclaim lost productivity. This has a profound effect on the shape of software teams and organizations, and in retrospect we come to see that our beliefs about organizational mechanics and culture were what kept us trapped in superstitious dark ages of software development productivity.

Regardless of whether tools like Microsoft Visual Studio (among others) seem impressive on the surface, failure to assess the effects of these tools on an entire pipeline will inevitably lead to mere momentary efficiencies and local optima. Worse yet, they will obstruct the learning that does in fact lead to productivity that matters, and will pull managers away from valuable work like teaching and facilitating and force them to become inventory managers and expediters.

It's not just the younger teams using Microsoft's visual tools who are subject to this problem either. Even advanced "agile" teams indulge in developer efficiency local optima like the hypercoding enabled by a higher order of developers tools. In some cases, hypercoding has even motivated urgent and wide-ranging changes to frameworks to optimize for a tool's use even in the face of compelling evidence that more meaningful sources of productivity are likely elsewhere. The compelling productivity of Ruby on Rails programmers despite the unavailability of extensive hypercoding tooling is a good example.

There's no one true answer to whether a tool is going to contribute to productivity. Sometimes just the creature comforts afforded by a tool are significant sources of productivity. But then, not all indulgences in creature comforts can be considered productivity enhancers either.

Ultimately, any of these tools can be used in a balanced, leveled software development workflow. However, until a meaningful understanding and representation of productivity takes root in software development, any team at any level of maturity is going to trade productivity that matters for mere efficiency.

Fixing the Problem

We can affect the things we control. When software projects go awry, we exert control. Any time we exert control without considering the impact on the entire fire brigade of software development workflow, we're going to create efficiencies at the expensive of our ability to produce.

The further away you are from the whole of the team and the workflow, the less likely you are to exert control constructively. As a senior manager, you might prescribe a suite of "Developer Productivity" tools after seeing a compelling presentation from a vendor that is specifically geared to affect your sensibilities from your perspective. If you're a developer, you might convince your team to adopt a "Developer Productivity" tool that demonstrably makes you a more efficient coding machine.

The decisions made by people who are too far from the whole are often a coin toss. There's little telling whether a team will perform better in getting products into the hands of the people who need them, and it’s often difficult to connect the decisions with the ultimate outcomes.

If you're encouraging or enforcing a team organization that disconnects the work and workers from the validation of their work, whether analysis work, design work, construction work, construction inspection work, packaging work, installation work, or operations work, you will inevitably create the conditions that encourage inventory build up and the subsequent obstructions, rework and general degradation of productivity. The shallow pursuit or mere localized efficiencies are more likely to happen when work centers fail to be shaped to productivity goals.

Making any of a number of mistakes that trade local efficiencies for productivity not only degrades productivity, but creates a cycle where the degradation accumulates, leading to the typical software cost curve that is ultimately a reflection of the degrading productivity curve.

Fixing the problem isn't trivial because no single local optimization will have a predictable effect, and a set of disconnected local optimizations degrade productivity even faster and even more unpredictably.

There's no doubt that we need to act on all levels, and ultimately this means decomposing the problem and working on different levels of an organization an at different work centers. But the local things we do to fix the problem have to extend from a holistic understanding of the software development system.

If you want to fix your software development system, find the problems with the system and then understand how the parts contribute to the problem. Evaluate the success of each effort to fix the parts by the effect that it has on the system.

Developer productivity can just as easily be a reality as a myth. Developers are obviously significant contributors to producing software. But an approach to "developer productivity" that isn't also an approach to organizational productivity is often not likely to do more than transfer value from your organization’s treasury to the coffers of a vendor who is more than happy to assume ownership of your precious resources.

We can’t get software done without software tools – this is true - but choose wisely. Your whole team’s productivity is at stake.

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

Relearning: The Productivity Problem that We're Not Supposed To Talk About

2009-07-08T00:42:00.013-05:00

Imagine that you had no memory; that everything you learned had to be re-learned again and again as you did your work. If you worked in software development, you wouldn't have to stretch too far to imagine it. Re-learning is so much a part of the moment by moment work of software development that it's considered normal. In fact, it's the unrecognized backdrop that software development plays out in front of.

Because relearning is not recognized as a problem as software development, it's almost never talked about it. And frankly, it's not a welcome subject in polite programmer society. Nonetheless, relearning accounts for a lot of unnecessary lost productivity and waste in software development. It can account for wide swings in productivity loss on most software teams, affecting the manageability of software projects and a truthful and meaningful assessment of programmers' real abilities as designers, analysts, problem solvers, and real contributors.

I'll offer an observation from my own experience and from the anecdotal evidence of others in my professional circle: I would be comfortable saying that half of the lost productivity on software teams comes from re-learning. It can come in the form of poor testability - the inability to easily provide proofs that expectations are met - and it can come in the form of source code that can't be understood at a glance. Even teams who have solved the testability problem still largely suffer from the lack of usability of their code, and the inevitable mass of relearning that comes of it.

First We Scan, and then We Read

Text in a text editor is interactive media; subject to the same fundamental usability principles that apply to a web page, a desktop app, or even a billboard on the side of the highway.

Before users read the content of interactive media they scan the content. Programmers scan
code before they read it. This is the singular human behavior that programmers consistently fail to recognize. It's the fundamental behavior that when recognized, becomes one of the pillars that code usability efforts can be built upon, and the starting point for recouping losses from relearning.

A singular focus on readability in code is a concern that, while encouraging, still misses the point. It's the same point that programmers missed as a human-computer interaction industry grew from the ashes of our continued failed attempts to create productive user experiences.

Usable code dissolves into understanding at a glance. It doesn't need to be coerced into understanding. I like to call this kind of code "soluble" code for the image it brings to mind of program text readily dissolving into awareness and understanding. Soluble code is likely readable code, but readable code isn't soluble unless it's written to be soluble.

Reading code isn't like reading a good article, where you start at the top and read to the bottom, enjoying the experience and being fulfilled by it. Granted there is beautiful code in the world, but the typical reasons for reading code are not the reasons that we read articles, books, papers, and the like.

In fact, the nature of the media that this article is published in, and the context that this media is typically consumed in, is such that you are more than likely to start jumping around the text with your eyes and with your mouse, looking for the nuggets and pearls while avoiding having to consume the entire thing linearly as it is written.

The first thing we do with code is ascertain whether it is indeed the code that we need to be working with in order to accomplish whatever task we've taken on. This even happens when we're reading code for the pleasure of it. The first eyes-on experience with some code usually involves rapid scanning of the code to ascertain if we're in the right place; if
we're at the worksite. Much of this happens pre-cognitively as it does with any media that we've been called to act upon. First we scan to get our bearings, and then we read.

We take high-level structural scans, followed by smaller, more detailed scans, followed by reading. If the code that we're scanning is written so that it only yields its meaning from a detailed read, then not only are we not optimizing for the natural human interaction patterns, we're also not taking advantage of providing the incidental knowledge that can be yielded to someone while they're scanning. This incidental knowledge accumulates and becomes a significant part of the material invested in the metal map of a codebase that a programmer accumulates through exposure to code that yields its meaning at a glance. We retain a codebase's textual geography only when we absorb its meaning.

If we don't code for solubility, we force programmers to take detailed reads in order to tease knowledge and understanding from the text. Forcing these detailed reads doesn't lead to greater advantage down the road. Less meaning is retained when forcing detailed reading into a context where a programmer is instinctively trying to scan.

Scanning is as much about a process of elimination as it is a process of accumulation. Both are happening at once during scanning unless code isn't amenable to these processes. If we fail to take advantage of scanning by failing to write soluble code, we're stealing productivity from our team mates, and from ourselves. On the surface, this seems like a negligible issue, but lack of solubility is responsible for a tremendous amount relearning and degraded productivity.

Solubility as a code style permeates a codebase. It's a pervasive quality; it has a constant, pervasive effect. Small improvements add up to significant advances when they have a pervasive effect.

Making Code Soluble

There are no cookie cutter patterns for making code soluble. Some things are obvious: meaningful symbol names (class names, method names, variable names, etc), and higher-level methods that tell the story of some process that call lower-level methods that contain the details. Both of these go a long way to create soluble code. Soluble code yields its meaning immediately.

The particular refinements that a team will make depends on the team, the product being built, the technology, and a host of other conditions. Pushing further for an canonical definition of soluble code patterns might lead to just as much productivity loss as productivity gain. Further practices, beyond meaningful names and anecdotal methods, are contextual and shouldn't be dropped into the code as if they are interchangeable parts.

Soluble code is an experience like the table of contents in a novel. It offers and allows multiple levels of reading, with each deeper level yielding ever greater detail. A table of contents is an affordance to the reader that acts as a navigational aid, or map, of the text. But a novel isn't program code. A table of contents at the beginning of a novel can be sufficient for that kind of media with its implicit user experiences, whereas program code itself must be it's own table of contents, right down to the very small, five-line, composable methods. The user of a novel is typically well-served by a table of contents whose resolution goes no further than mapping out chapters, expecting the reader to start reading linearly from the beginning of the chapter. But this isn't the case with program code.

When we're scanning, we're mapping the code by the what of the code; what the code does, what it's responsibilities and behaviors are. Soluble code allows a reader to immediately understand what is does before forcing the reader to understand how it does it. Soluble code serves both modes: scanning for what, and reading the how. Code that isn't styled this way largely deprives a user of the process of elimination, the incidental knowledge, and the mapping that can be had from scanning.

One of the worst mistakes that programmers make in writing code is in failing to recognize that more productivity will be spent over the life time of code navigating through the code than will be spent writing the code. It doesn't take much more effort to write soluble code that serves the elimination of relearning. Choosing to not write soluble code means choosing to keep the relearning waste well-entrenched, but there's more to this problem than mere choice.

Resistance to Code Usability

There are reasonable objections to styling code for solubility and usability. The how
of the system ends up spread over many small methods rather than concentrating it in fewer, larger locations. The root cause of the aggravation is often not that the code is factored in
small semantic units, but that the semantic units are not the right ones, or that the factoring is just not good. Yes, this is the you're not doing it right response, and as unfashionable is this response is, it can nonetheless end up being the root cause. Nonetheless, some programmers are just not going to want to get used to soluble code style, and there will be inevitable grumblings from people who prefer to use more traditional, procedural structure. It's not hard to bring usability to code, but it can be discomforting at first - like transitioning to a new programming language.

Programmers aren't traditionally the folks on a software team who have their heads in the usability game. And we've gotten to an unfortunate point in programmer culture where the answer to many subsequent problems with programmer ineffectiveness has been to create further specializations and allow programmers to be responsible for a narrower and narrower set of expectations rather than deal with knowledge problems as organizational and cultural problems.

Expecting programmers to be considerate of code usability creates friction. For many programmers it's going to be as comfortable as thawing out frozen, front-bitten fingers. But it's not just a programmer responsibility. A good chunk of the responsibility for change rests squarely with the surrounding and supporting organization and its protocols and mechanics. There's more to rehabilitating software development productivity than introducing programmers to new coding pattens. Organizations that have a commitment to learning cultures will do much better at this.

The staunchest resistance to efforts to reclaim lost productivity due to relearning will come from hero programmers. Hero programmers are those guys in any organization that can get the job done with any code in any state. They are typically blessed with what seems like a supernaturally high-definition mental map of a codebase. This is their best and worst quality. It's their best quality because they often know where to fix a problem in a codebase and have a reasonable grasp of the myriad side effects that might result. It can be their worst quality because it's often an effect of mild Asperger Syndrome common to programmers, engineers, and jobs that require extended, intense focus. It's often accompanied by the lack of awareness and empathy toward peers typical to the condition.

Hero programmers can suboptimize the efforts of a team by not having to rely on soluble code, often navigating a codebase entirely from memory. The ability can be incredibly useful, but the need to write soluble code rarely manifests because it's not a personal need, and the typical lack of empathy obstructs the ability to recognize how this advantage undermines their team mates' efforts to be as effective.

The code created by hero programmers isn't soluble because the heroes rely on uncommon facilities that preclude the need for solubility. They don't notice the design smells because they rely almost exclusively on echo location for navigation. The resulting work product can often only be as effectively worked on by the heroes themselves, which inevitably leads to predictable resource bottlenecks, bus factor risks, excessive specialization, and the general malaise on a team as the effects of code toxicity spill over into the human realm.

The analogy to the baseball shortstop who was famous for making great plays applies: his coach often pointed out that he was out of position to begin with.

Usability is rooted in an ability to have empathy for users. That empathy gives designers the pause to consider whether they got the user experience right. It's the empathy that leads to the questioning that leads to the recognition of interaction design problems in the form of cognitive obstacles that undermine the user's productivity. In an environment with traditional and institutionalized lack of awareness and lack of empathy, dysfunction can drive unconscionable waste.

Hero programmers rarely stop to question whether they've left behind a good experience for others on the team who need to navigate, then understand, then make changes to the code. And most programmers will fail to recognize the two distinct mindsets that are in play when working with code.

Writer's Mind and Reader's Mind

Without ever doubting whether code is usable, programmers will presume that the right thing has been done. Programmers who are good at creating soluble code have learned to doubt every line of code written. It's not that they have all of the answers. More importantly, they've learned to be constantly questioning.

In the words of the anthropologist Claude Levi-Strauss (not the guy who invented blue jeans), "The scientific mind does not so much provide the the right answers as ask the right questions."

Asking the right questions means constantly switching from the writer's mind to the reader's mind. That means that after each bit of code is written, a programmer switches mental contexts and assesses the code from the perspective of someone who has never seen the code before, asking, "What have I done to undermine the immediacy of someone else's understanding of my work? What unrecognized presumptions have I made about their context as a reader that only applies to my context as a writer?"

That's quite a trick, and it's not uncommon to hear the complaint that it can't be done, but it's what interaction designers do all the time. It's not uncommon for the deleterious effects of programmer autism to cause programmers to fail to have awareness sufficient enough to break out of the laser-like focus on writing code and switch back into questioning.

Code that doesn't incur the cost of relearning is code that can be immediately understood by someone who hasn't seen it before with minimal orientation to the code and the problems it solves. It's code that can be understood at a glance. That code is rarely if ever produced by a mind that has lost its awareness of its context and its mode. It isn't produced by a mind that fails to concede that code is written to be read, that the readers are other humans, and that the reader's context and needs are not the context of the writer - at lest not until the reader has found the worksite in the code, and gained sufficient understanding of the worksite to begin to make the necessary changes that they're tasked with.

The writer's mind is a context that often fails to recognize that the focused and relatively linear mechanics of writing code is quite different than the mechanics of consuming code as a reader. And this is where the misconception over readability comes from. The writer's mind, working relatively linearly is also consuming code in that mode. Readability is a quality that pertains to the linear consumption of code as text, and that kind of optimization of experience is only relevant some of the time in some user scenarios.

Break the Habit

The autistic mind is lulled by the hypnotic cadence of constantly pumping out code. It will complain that the constant switching between the writer's perspective and the reader's perspective is ruining their ability to get in the zone. And in truth, it is, but it's that particular zone that is causing a lot of relearning debt to mount up. There are other zones to get into with equally pleasing effects, but it is a matter of breaking some habits and replacing them with new ones. There are a few tricks and techniques that programmers can use to break out of the fog and get into the zone.

The most important thing to practice is the constant self-questioning of whether the code just created is soluble; that it can be understood at a glance and yields enough meaning while scanning to contribute to the mental map. Instead of presuming that everything I do is made of gold, I presume instead that it's made of fools gold. From that perspective, I can usually gain the right amount of objectivity to assess solubility.

Pair programming and test-driven development are two techniques from Extreme Programming that are extremely effective at clearing the fog. When these techniques are practiced together, it becomes very difficult to be lulled into the unexamined mind that produces unexamined code.

If you don't like pair programming, try using some kind of timer on an interval that is just short enough to be uncomfortable that will remind you to come back up for some critical thinking.

And lastly (for this article anyway; there are more tricks out there), Context Specification is a form of Test-Driven Development that recognizes solubility, usability, reader's mind, and authorship, and forces the issue of contextual analysis to bring more practice of awareness into programming.

Commit to Learning

Ultimately, there's no where left to hide. The anti-productivity that comes from inviting and accepting relearning continues to accumulate. We've pushed it into the lowest level of software development where only programmers can (or may) see it, but it still affects everyone touched by the software project or the product.

Relearning waste is a fundamental organizational behavior. Until we shape organizations around dealing with waste and learning, we continue to fail to see in the range of the spectrum where the sheer magnitude of the relearning waste is visible. Relearning is inculcated into software organizations. Shifting from re-learning organizations to learning organizations and learning culture is how this problem is ultimately solved.

It's self-evident: counter-act relearning with learning. The term learning organization isn't the trite and trivial perspectives that see learning as something external to team and organization; a destination where people are sent once in a while to be "trained". Learning is no more about receiving training than quality assurance is about giving click recorders to test monkeys. The emphasis we put on "training" in the software industry undermines our ability to see the "learning" side of the same issue, and to build truly meaningful teaching/learning experiences in our organizations, and to subordinate organizational mechanics and protocols to these imperatives to counteract the constant, tireless forces that drag us back into relearning.

The value we throw away on relearning is recouped when we counter it with meaningful learning. Learning gets real when it's expressed in every organizational protocol and business process, and importantly for software development, when it is expressed in every single line of code written by everyone involved in bringing a solution to life.

The Problem with Big Design Up Front is the "Big" not the "Up Front"

2009-07-03T22:40:00.000-05:00

The risks of Big Design Up Front isn't the "Up Front" part, it's the "Big" part. Doing too much design without validating it inevitably drives a good bit of the productivity loss that continues to hamper software projects.

It's an issue of large batch sizes - the "Big" in "Big Design Up Front". The larger batch sizes mean that we're always building today's software on yesterday's work and yesterday's decisions before proving that yesterday's work and decisions are sound. The larger the batch size, the larger the risk that the incorrectness of design will lead to ever more expensive countermeasures. And in many cases, design flaws are too subtle to be seen immediately, and collect negative potential energy in the form of on-going degradation in productivity that came to be seen as "normal".

Big Design Up Front has often come to be interpreted as "No Design Up Front", and has led to a lot of mediocrity in design by inappropriately democratizing the responsibility for design quality. This is often done in the name of cross-training, but the best way to teach potential software designers to be good software designers is to constantly expose them to good software design, rather than the mediocre design that can come from a misinterpretation of Big Design Up Front.

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

Designing the Work

2009-07-03T22:27:00.004-05:00

More than just designing the software, technical leadership must also design the work of implementing those designs. Taking the shape of the work into consideration along with the shaping of software modules serves the goal of predictability that comes from leveled production, and the awareness of trouble spots. Designing the work serves human and organizational concerns, and predictable manageability.

Decomposing requirements, be they user stories, features, or what ever you use in your process, is inherently a design activity. Division of labor follows the division of software modules, and the division of software modules also follows the division of labor. These design activities have to be done in consideration of each other, likely by the same people and at the same time.

The design should be communicated to the team, and at the very least, to the members of a team who might be tasked with the work, but it isn't necessary to have the whole team involved in creating the design. The best designers should be involved in doing the design work. This should go without saying, but some of the interpretations of "self-organizing team" can contribute to obscuring the obvious: individuals on teams do indeed have strengths, and some are stronger than others.

Communicating design and expectations is a great side effect of all-hands planning and estimation, but it can create poorer designs that are normalized to the average skill on the team while the team learns how to design software. Becoming a competent software designer takes many years of work and the uncanny circumstances that create the precursors of design awareness that, when complimented with experience, creates the talented and mature abstractionists, analysts, implementers, and engineers who lead design efforts. Planning and estimation and teaching and design do share some common ground, but teaching design and growing designers should be an explicit goal with specific work, rather than a magical side effect.

Decomposition, task breakdown, and scheduling are all aspects of design. When we communicate design to the people doing the implementation, we're setting expectations for their work. When we set expectations for people, we (hopefully) activate their critical minds. They inevitably cross-check a work plan and inevitably cross-check the design as they learn about the plan. That's not exactly the same thing as the design-by-committee exercises that are too frequently the result of consensus estimation design, where decomposition is often done as part of whole team sessions that are concerned with dialing in agreements on story points.

Designers front-load the design, bringing their experience and aptitude for design to bear, and provide structure for the ensuing conversations. The tension between the design and the cross-checking can lead to new insights. It can lead to changes in the scheduling of the work and it can lead to changes in the design, but it's not a consensus-based free-for-all that leads to the mediocratization of design. The front-loaded design done by competent designers produces a more balanced equation, especially when they are also designing the work.

This isn't Big Design Up Front or phased-based SDLC though. Designing the work simply means that there's necessary front-loading involved in producing software. Front-loading doesn't preclude inspecting and adapting, responding to change, or emergent design.

The balance between good work that can be continually built upon, work that creates lower standards of productivity, and work that can be managed to expectations hinges on more than good software design. Software development productivity lives at the intersection between well-designed software and well-designed software work. Agile estimation is a good start down the road to manageable software development. Designing the work closes the gap between the beginnings of manageable work, and work that can be managed.

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

Flow, Leveling, and User Stories

2009-05-25T00:59:00.010-05:00

Flow and leveling are two sides or the same multi-sided shape. The goal is an understood and controllable cycle time. Without leveling, sustained flow is unlikely. Without flow, improvement is less observable and manageable. Improvement efforts might be rooted more in medieval software superstitions than something closer to a science.

David Anderson talks about the core of Kanban as an agreement that the team has a capacity; that they can only work on so much at a time; and a limit set around that work. Implicit in Lean work management styles is the right-sizing of work items. Reducing the broad variability in work item sizes is a part of the work that goes into flow and into controlling cycle time.

Typically, in a method like Scrum, a team organizes its work efforts around user stories. The user stories that are worked on during an iteration (or sprint) can be any of a number of sizes. Using the Fibonacci estimation technique the variation in story size can be almost infinite.

User stories are a way to communicate expectations, but they're a less effective way to manage work and improvement because of the amount of variation allowed in user story sizes. You could decompose stories into smaller stories so that they're more manageable, but then you'd risk fragmenting the communication value of stories by breaking them into separate chunks that might not carry as much context as the original larger stories.

User stories can be of variable size because they inherently are of variable size. Let user stories be the size that makes sense for the kind of artifact that user stories are: an artifact intended to communicate context and expectations to the development effort. Use right-sized work items to manage work. Decompose user stories into work items and schedule those work items for development in way that takes both customer priority and technical constraints into consideration.

The work items can certainly be linked back the stories that they are decomposed from, but it's the work items rather than stories that go through the development pipeline.

I've sat through enough all-hands Agile planning and estimation sessions to know that while this practice is useful for bringing a new agile team together, it's often a terribly ineffective way to establish design. It's a good way to socialize design, but there are alternatives that don't imply the wastefulness of traditional Agile planning and estimation. Using design as a team-building exercise can put the design at risk.

In the worst cases, the all-hands planning and estimation that is common to Agile development methods can hurt the team. It's just as likely that adversarial conditions can break out in the team if an expectation is set that suggests that product design and implementation design are egalitarian and democratic within a team that is necessarily staffed by people of varying experience and ability.

Design should be done by those who are most capable of doing design. Story decomposition should be done by the person or people who are best equipped to do that work. This doesn't preclude the socialization of that design to the team and the proving of that design by the team.

Rather than all-hands estimation and planning, design and planning can be done in short, effective sessions with the team's designers. Since designers are decomposing to work items that are intended to be of a similar size, the team no longer estimates work, but reviews the decomposition and seeks clarification and raises concerns. The collective intelligence of the team is still leveraged, but the potential waste and ineffectiveness of traditional Agile planning is avoided.

The planning and estimation activities change from larger-scale chunks of time, effort, and team participation to smaller units of tiered work and cooperation that can be done just-in-time rather than on those specific days of the week when the whole team's attention can be coordinated and directed to a fixed-schedule meeting. Consequently, any all-hands team meetings can be scheduled on an as-needed basis as well, eliminating any waste that comes from institutionalizing all-hands meetings according to a fixed timebox.

With planning, design, and scheduling being done in smaller units on a just-in-time basis, some of the fixed time boxes in the development process aren't needed. Features can be queued for packaging and deployment on an opportunistic basis as well. There may still be some fixed rhythms at-play in the effort - customer demos and major market events, for example - but these synchronization events don't have to leak their scheduling mechanics into aspects of the work that aren't dependent upon or necessarily coupled to those rhythms.

Work items aren't just same-sized, they're also small-sized. The larger the work item, the more variability there is between the estimate of the work and the actual work. We understand larger work items with less certainty than smaller work items. That's because decomposing work into smaller items means that we have to think about the actual units of design and work that go into delivering those bigger features. Because we're trying to achieve flow in pull-based systems, the variability inherent in larger work items is a likely obstruction.

The specific amount of work that defines what "small" is depends on the kind of work, the team, and a handful of factors. And the actual size of "small" will likely change over time. In some cases, it might just be impossible to get all work items to be of similar size. Consider whether the work can be scheduled so that groups of similarly-sized work items can to be done together.

Without leveling, flow will continue to be difficult, and Kanban a Japanese word that has come to mean "story wall".

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

Pull Harder to Find Problems with Flow, and Improve From There

2009-05-24T16:14:00.002-05:00

A focus on flow that leads to continual observation of the health of flow lets us use flow to improve organizational performance. Once flow is happening in a pull system, pull harder. Pulling harder will show you where the next level of obstructions is in your organization that keeps you from the next level of performance.

Lean and Kanban are geared to performance improvement, and their principles are applied regardless of the development process in-play, and in concert with the existing process. As opposed to something like Scrum, Lean doesn't require the wholesale, instantaneous replacement of existing processes with a prescriptive process template like Scrum (or others).

Using Lean principles and Kanban will show you the hotspots in your process where you might need to focus your improvement efforts. The software process mechanics that you end up with could very likely end up looking a whole lot like a prescriptive Agile development process, but the adoption and use of specific practices and mechanics are driven by tangible need, based on the repercussions of several instances of pulling harder and deploying and observing the countermeasures that clear out the chaotic oscillations that result immediately from pulling harder.

Pulling harder means increasing the expectations for the capacity of the system. Lean organizations aren't sitting on their laurels. Successions of pulling harder, solving the resulting organizational, process, and mechanical problems, and understanding and working with resulting performance improvements is Lean's continuous improvement. Continuous improvement means an inculcated value system that doesn't allow its past achievements to distract from the next level of goals, and the inevitable ardors of reaching them.

The organization is there to serve the goal. A Lean organization isn't a goal in and of itself. The organization bends to serve the nexus of value creation at the center of the vaue-add work. An obstruction to the ability to successfully pull harder might be found in a part of the organization outside of the immediate product development team. If that's the case, it's understood that the system as a whole must be optimized in order to continue to improve performance.

Once you've got your bicycle up to speed, pedal harder and see what might get in the way of being able to. And then devise and manage a well-considered plan to adapt the process and the organization to get those obstructions out of the way.

Pulling harder creates process improvement simply by setting expectations that are designed to clearly and brightly illuminate the ugly obstructions the lurk in organizations and processes and even in the tools being used. Simply: improve by improving. Set new expectations for the well-understood process and team and take a principled approach to understanding and working with the team's capacity.

Merely overlaying new process templates on a team isn't really the most reasonable and effective approach to improving performance. A change in process should be goal-driven and executed methodically. You might make some sweeping changes in the process, but the wholesale adoption of something like Scrum's agile project management prescriptions isn't likely necessary, and in some cases such a course might exasperate the effort for performance improvement.

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

Flaccid Kanban

2009-05-22T22:56:00.006-05:00

A few shops in my professional community have started flying the Kanban flag. This is potentially a great step forward in opening the agile software development dialog to a more rigorous understanding of value, especially in how value is lost and how to defend development efforts from the pervasive value leaks in end-to-end workflows.

XP and Scrum shops - especially those with people with significant XP and Scrum experience - might trip over their unrecognized biases at first.

Iterations and Rolling Wave

Kanban doesn't require iterations. Scrum and XP work management doesn't magically transist into Kanban when we remove iterations. What we get from iteration-less Scrum and XP is Scrum or XP with rolling wave planning. Regardless of the benefit of rolling wave, it's not really Kanban until you're asking (and answering) some fundamental questions about work management, organizational performance, and value.

What is the purpose of Kanban?

The purpose of Kanban in software isn't to merely ditch the overhead of iterations. That overhead is a form of waste that might be avoided when iterations are taken out of the picture, but depending on the surrounding context, just as much compensatory waste might be created when iterations are removed.

The purpose of Kanban - other than visual control systems - is to limit work-in-progress in relation to a team's capacity in order to become sensitive to opportunities for improvement and to see waste and value loss (attribution: david anderson). But it's not enough to just announce in a team meeting that context-switching is now verboten. There's a point to limiting work in-progress, and there are a good number of inter-related practices and principles that benefit the work and the management of the work that come into play.

Flaccid Kanban

Martin Fowler recently wrote an article entitled Flaccid Scrum. The article calls attention to a Scrum implementations and adoptions that try to achieve agile software development's promise without implementing anything but agile project management, ignoring the engineering practices that allow agile project management to yield the promises of agile software development as a whole.

As Lean gains popularity and adoption, it becomes susceptible to the degradations that come of mainstream opportunism. Kanban adoption into relatively mature XP teams seems to be creating a sort of Flaccid Kanban - implementations of Kanban that more or less disregard the underlying reasons and mechanics of Kanban.

The real loss here is that we tend to stop looking for something once we believe we've found it. What has been frequently adopted lately that has been called Kanban appears to be merely rolling wave planning. Not that there's anything wrong with rolling wave, it's likely a necessary component of Kanban in software development, but there's nothing good about reaching for Kanban and coming up short because of the temptation to use Kanban in-name-only merely for the fashionista value.

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