Interesting piece in yesterday’s NYTimes Business section by Mary Tripsas on how 3M partners with its customers to drive innovation and new ideas, as opposed to driving their innovation into them with a blunt instrument:  Seeing Customers as Partners in Innovation.  While 3M should be immediately familiar to most folks, it’s even doubly-so for software development professionals who employ lean delivery techniques since one of the acknowledged thought-leaders in the space is Mary Poppendieck, a former 3M employee.

The article references a Harvard Business School professor, Ranjay Gulati, who has recently completed a book I need to pick up:  (Re)(Organize) for Resilience: Putting Customers at the Center of Your Business.  His approach is definitely in simpatico with the agile/iterative/lean philosophy:

“Being customer-driven doesn’t mean asking customers what they want and then giving it to them,” says Ranjay Gulati, a professor at the Harvard Business School. “It’s about building a deep awareness of how the customer uses your product.”

This stands in stark contrast to how many firms perceive their customers, developing a homogenous view of their base through their product lines and offerings.  In this environment, innovation becomes an ugly stepchild – something I’ve witnessed more and more in the industry.  Gulati has seen this as well, and shares my cynical perspective:

The terms “customer driven” and “solutions” seem to be in every manager’s lexicon. But as Professor Gulati notes, “it’s an execution problem.” Companies, he says, “aren’t generally structured to access, absorb or utilize customer insights since they are organized by product, not by customer.”

And so we have the defining challenge of our industry which I am flummoxed to explain:  Why we are retreating to view software development as the end-product of a manufacturing vs. creative process, especially in light of the failures the former view has wreaked.

Within MCS, I am seeing this increasingly coming to the fore with a shift toward fixed-bid projects that limit the ability of consultants to drive the kind of rich innovation Tripsas’ article describes or the deep partnerships that Gulati promotes.  When we view customers as fitting or shoe-horned in to categories, we begin to constrain our thinking around our products which shutters our view of more exciting opportunities that would otherwise come to the fore.

In my opinion, if we adopt an “Innovation Center” approach as Tripsas describes, we may in fact develop a defining competitive advantage and so break out of the constraints of being organized by product and not by customer.

In my inbox today was a copy of Dr. Dobb’s Update Newsletter (Dec 10/09) with the Editor’s Note on the recent SEMAT Initiative that’s been launched by the likes of Ivar Jacobsen (UML and Rational Unified Process), Bertrand Meyer (Eiffel language and Design by Contract paradigm) and Richard Soley (Chair/CEO of Object Management Group – Standards around distributed OO systems, CORBA). 

SEMAT is an acronym for Software Engineering Method and Theory, and has been pitched as a community of professional, leading software industry researchers and computer scientists “united” with the aim of providing a unified theory to re-establish “software engineering as a rigorous discipline based on a solid theory, proven principles and best practices.”  Already, my eyes were rolling and my BS sensor was tingling.

However, in an attempt to woo folks to their island, they list some of their signatories, including folks like Scott Ambler, Barry Boehm, Alistair Cockburn, Larry Constantine, Erich Gamma, Capers Jones, Robert C. Martin, Ken Schwaber and the like.  Very impressive.  Also a dead giveaway that this effort will be largely symbolic and not bound to produce anything substantive.

What I find troublesome about SEMAT is its aims – I really do not subscribe to the notion that there is a single theory to describe software development and engineering because of the almost infinite variability of its primary inputs:  Human creativity and collaboration.  This is why I subscribe to agile/iterative/lean practices that emphasize incremental delivery with frequent inspect/adapt feedback loops.  It’s the best way to manage the chaos and drive value.

Not good enough for SEMAT – they see the need for a revolution:

Software engineering is gravely hampered today by immature practices. Specific problems include:

• The prevalence of fads more typical of fashion industry than of an engineering discipline.
• The lack of a sound, widely accepted theoretical basis.
• The huge number of methods and method variants, with differences little understood and artificially magnified.
• The lack of credible experimental evaluation and validation.
• The split between industry practice and academic research.

What a poor choice of words overall to build a case for a call to action to come up with some rigid specification and theory about how people come together on a complex endeavour to produce working software.  And of course, what we need is more research and theory rather than practical, readily-applicable strategies to build software.

They go on:

We support a process to refound software engineering based on a solid theory, proven principles and best practices that:

• Include a kernel of widely-agreed elements, extensible for specific uses
• Addresses both technology and people issues
• Are supported by industry, academia, researchers and users
• Support extension in the face of changing requirements and technology

And other mom & apple pie things. 

Lessons Learned from ALT.NET

While these a laudable goals, they’re impractical and not likely to be achieved, if for no other reason than the folks involved (personality clashes and the like).  However there’s another reason I think this will not go far, and it’s because I’ve seen it all before in the ALT.NET initiative.

ALT.NET was (is?) a loose confederacy of software development professionals, founded by NY developer Dave Laribee in early 2007.  The intent was to provide a community for “alternative” .NET professionals: Like-minded folks who used .NET technologies, but weren’t slavishly dedicated to a Microsoft-centric view.  The mantra of “the best tool for the job” was frequently repeated in the early days.

They scored some early wins with Microsoft’s Scott Guthrie announcing the release of ASP.NET Model-View-Controller (MVC) components at their premier open space meeting in October 2007, and there were lofty plans to help open chapters around the world.  A wiki was set up and the community (me included) began to help build a repository of best practice reference material.

Things went well until later that year and into 2008 when the community began to descend into infighting and a lot of rather harsh criticism that they were becoming to “cliquish” – some of the founding members ended up walking away and today, after taking the development world by storm and spawning dozens of podcasts, ALT.NET languishes in relative obscurity. 

The chief problem became the perception that ALT.NET was issuing decrees about what it was to be truly “ALT.NET”.  As a result, it became quasi-religious and so began to take on a spectrum of adherents with varying degrees of dogmatism.  You were either “with us” or “agin us”, a nary the twain shall meet.  Thus, I foresee the same problems hampering SEMAT:  It will collapse under its own weight as the signatories and signers-on get spun out in debates over whose methodologies or practices are better and what should be tested and what should not, and how and for how long.  In the end, it will winnow down to a small cadre of dogmatists who will have forced a good many people away.

And for what?  A fantastical “unified theory” of software development that doesn’t exist, nor will it ever.

Footnote:

For an excellent critical treatment of the out-of-the-gate problems with SEMAT, see Jorge Aranda’s Nov 29/09 blog post, Against SEMAT.  He raises some excellent points that I won’t bother to reiterate here.

Take a look at this – the future of small business transactions has been realized by a startup called Square:

Their vision is to enable any small device with an audio jack to be able to process credit card purchases:

… and provide instant email receipts:

Really inspired thinking here – this is one of those revolutionary products that can act as a catalyst to power-up all kinds of entrepreneurial ventures.  Really smart design.

Square is still in beta, so availability even in the US is limited.  Canada – fuhgeddaboudit.

Missed this one – on November 19/09, Microsoft launched a new TechNet site, Update Center for Microsoft Office, Office Servers and Related Products, that consolidates the hitherto somewhat scattered updates for their Office and Office Server stack.  It now provides an up-to-the-minute dashboard of the latest released service packs and security updates – with RSS feeds, of course.

Previously, a really reliable source for this kind of info was the SharePoint Product Team’s blog (still is), but their content, esp. around service packs, hasn’t been consistently tagged of late which can lead to some confusion.  I’d recommend keeping both sites in your pocket so you can get a good overview of the current patch state for the stack.

I recently came across a Nov. 25/09 post on Davy Brion’s blog, The Inquisitive Coder, that enumerates his recommended reading list for software developers who are wanting to step up their game.  This is a common theme on coding blogs, and there have been literally a galaxy of postings with some great and not so great recommendations guaranteed to perplex and flummox the average coder.

The implied line with all of these articles is that you ignore these tomes at your peril – you just won’t get to the “A” levels without them.

I like how Brion has broken his recommendations into three strata according to developer experience:  newbie, sophomore and grizzled veteran.  Well, sort of.  I mean, learning agile/iterative/lean software development really should occur at the start of your career as you’re going to have to unlearn the BDUF/waterfall crap that was loaded into your head by your CS/SoftEng profs who last “delivered” software (if at all) when 8–bit CPUs were da bomb.

What I don’t like is the complexity of some of the volumes that Brion shows – some of them are just so dense as to be inaccessible and not immediately applicable, eg. Eric Evans’ Domain-Driven Design.

Read/Master These Books First

If you want to get immediate benefits, try this shorter reading list:

1. The Pragmatic Programmer:  From Journeyman to Master (Hunt & Thomas)
2. Pragmatic Unit Testing in Java/C# (Hunt & Thomas)
3. Refactoring:  Improving the Design of Existing Code (Fowler)
4. Practices of an Agile Developer (Subramaniam & Hunt)
5. Agile Software Development with Scrum (Schwaber & Beedle)

These books will help you begin to develop good habits – and in some places, possibly fired for wanting to implement.  That’s ok, because you don’t want to waste your life there, anyway.   It should take you 6–12 months to get through these and really internalize the practices and make them second nature.  I’ve recommended #5 because, as I mention above, you should get exposure to agile practices like Scrum sooner rather than later.

Read/Master These Books Next

You’ve got a couple of years under your belt and have seen the good, the bad and the ugly in the industry.  You’ve likely been on some bad projects and you’re beginning to question the wisdom of your chosen career path.  Take solace in these books to notch your game up further:

1. Design Patterns (Gang of Four – Gamma, Helm, Johnson, Vlissides) – Alternatively, any book that explains patterns in your language of choice will help you “grok” them.
2. Clean Code: A Handbook of Agile Software Craftsmanship (Robert “Uncle Bob” C. Martin)
3. Agile Estimating and Planning (Cohn)

By the time you get through these (another 6–12 months) you will be truly cynical about the state of the industry, as well you should.  But you’re not wanting to be a “mort” or a “501” kinda coder – you’re wanting more.  So, you should supplement the above list with these titles:

1. Death March 2^nd Edition (Yourdon)
2. The Mythical Man-Month (Brooks Jr.)
3. Agile Project Management with Scrum (Schwaber)

These titles will give you the intellectual “legs” to position your strategies and arguments (yes, arguments) for implementing best practices with peers and managers.

Ongoing Professional Development

After you’ve reached your fifth or sixth year in the industry, you should have a pretty good idea about who you are professionally and where you think you’re headed:  Leadership, Consulting, Management.  Depending on your path, different books will influence your thinking.  You will likely be wanting to show what you’re capable of – perhaps in a new role or firm.  Some of these titles will help:

1. Fearless Change:  Patterns for Introducing New Ideas (Manns & Rising)
2. Agile & Iterative Development:  A Manager’s Guide (Larman)
3. Implementing Lean Software Development:  From Concept to Cash (Poppendieck)

Conclusion:  Just Do It

In my experience, not very many folks who have a lot of “paper” experience have actually ready many of these books.  They’ve heard of them, but never read them or applied their lessons.  I’ve come across consultants who are really smart and with scads of experience who have yet to write a single unit test – or worse, think that a tool can do it all for them.  Common sense ain’t so common.

If you master 60% of the above list, you will be a better coder and professional than 3/4 of the people you’ll come across over your career.  It will take time, some personal commitment and in some cases risk – but it will be immediately worth it.  Follow the advice of Ken Schwaber (co-creator of Scrum) who urged attendees at a conference to actively begin improving their software delivery experience by implementing agile techniques by getting out there and doing it:  “Don’t procrastinate; do something – no matter how small.”