State of the Practice - 2010

Better Software and Agile West are concurrent conferences organized by Software Quality Engineering (SQE.com). Both conferences offer the opportunity to explore and share current best practices in software development and to find the common ground between traditional and agile approaches. A quick glance at the program shows CMM topics on the Agile side and XP topics on the Better Software side - revealing that there is a lot of common ground. This years conference was held at Caesar's Palace in Las Vegas, and it seemed to be a good opportunity to sit down with several leading practitioners, authors, and presenters and get their insights into the "State of the Practice in 2010. InfoQ talked with (in alphabetical order):

• David Hussman, of DevJam
• Tim Lister of Atlantic Systems Guild and co-author of Adrenaline Junkies and Template Zombies, Waltzing with Bears, and Peopleware
• Michael Mah of QSM Associates, Inc. and director of Benchmarking Practice at the Cutter Consortium
• James Martin (Uncle Bob) founder and president of Object Mentor and author or editor of numerous books including Agile Software Development: Principles, Patterns, and Practices
• Pollyanna Pixton of Accelinnova and co-author of Stand Back and Deliver: Accelerating Business Agility
• Johanna Rothman of Rothman Consulting Group, Inc.and author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
• Bill Wake a senior coach with Industrial Logic, Inc. and co-author of Refactoring in Ruby
• Rebecca Wirfs-Brock of Wirfs-Brock Associates and lead author of two books on OO Design, (Designing Object-Oriented Software, and Object Design: Roles, Responsibilities, and Collaborations

Each person was asked the the same set of questions and their answers were combined and summarized.

Can you name three current software development practices that are both "new" and "important?" (New might mean simply an old practice that has gained new prominence.)

Test-driven Development and automated testing made everyone's list with Michael Mah noting that the new found emphasis on testing finally provides some foundation for the claim to be software 'engineers.' Refactoring was a close second, but most of the respondents suggested that refactoring and refactoring browsers offer a lot of potential, but worry that teams are not always given the time to actually refractor to the degree desirable and necessary. Other practices that were mentioned, in order of frequency: continuous integration (even for waterfall projects), user stories (as work unit and time box) and story mapping, polyglot programming (driven largely by Web development), programming by intent, open-space environments, retrospectives, and acceptance of the appropriateness of agile for any kind of project.

Several respondents suggested that there is an emerging practice that should be noted - the separation of business analysis from projects, (putting together a rational set of user stories / product backlog before projects begin) maybe by a different team.

Overall and industry-wide, is software development today really different from what you would have seen in a survey review done in 1980?

This question elicited an interesting pattern of responses - almost everyone initially said no change. As Bob Martin noted, "things are different in form, not substance - we are still doing IF's, Assignments, and loops, coupling and cohesion are still critical, and lessons learned then are still important today."

The initial answer was almost immediately followed by an "and yet …" followed by noting some important differences. For example:

•  today there is a real software industry with the possibility of gluing off-the-shelf products to generate custom and useable software. This yields two very different kinds of software shop, the integrators (and vendors of massive integrated solutions) and the one-off producers.
• Most believed that Agile brought together a lot of older ideas, but integrated them in a new way to create a novel philosophical basis for thinking about software, one that emphasized creativity, quality, and increased responsiveness to business needs in "business time." Several respondents noticed an important, attitudinal, change: developers taking ownership of the process of development and exhibiting an increased sense of accountability and personal responsibility for the work. A consequence of ownership has been an increase in the respect for the idea of 'prototyping to production,' something that was considered taboo in the Eighties.
• Everyone raised the issue that we may be doing the same kinds of things, but we are addressing more "wicked" problems and trying to build far more complicated stuff. It was noted, however, that this change in complexity and the speed with which we deliver it has merrily resulted in bigger, and perhaps evolvable, "Balls of Mud." The fact that we have very different kinds of platforms, most importantly the Web, parallel hardware, and Cloud resources also have changed things from the 1980's.
• Michael Mah noted that we are building "amazing new stuff, interacting networks, distributed collaboration, social networking, and we are doing it faster." Unfortunately, at the same time bugs have increased by 75% - we are building crap faster - and we are piling up technical debt that will have to be addressed sooner rather than later."

In 1980 it was all about the mainframe; today it is all about The Cloud. Any differences?

Architecturally, the Cloud is just a big centralized platform connected to a large number of intelligent terminals - it is a mainframe in that regard. But there are important differences as well. As a resource, the cloud is highly configurable and far less expensive than trying to 'own' similar resources. The Cloud is also infinitely configurable, flexible, and customizable - something that the old mainframe was not.

There are huge security issues with the Cloud and concerns about whether or not you want your most sensitive data, "out there." There is too little known about what kinds of 'catastrophic failures' might occur in the Cloud and the affects such a failure might have on a company, an economy, or even the security of a nation.

The Cloud is also changing informational relationships - no longer can you use the excuse, "it's on my other computer at home." Having so much information out-there will also affect decision making possibilities and even usher in a new era of collaborative and distributed decision making. There is a potential for the Cloud to accelerate the current trend of hyper-integration along with the very real problem of lock-in and of "selling your soul" to the vendor of massive integrated applications.

Most of the real issues surrounding the Cloud are not technical - not a result of it being a 'mainframe in the sky" - but are business and social in nature and will have to be solved on that side of the house.

Agile is Mainstream! Does that mean it has succeeded or failed?

Both. It has mostly failed because, "everyone is doing it, everyone is doing it differently, and no one understands what they are doing." It has succeeded in the sense that it makes some people and some companies money and because "those crazy ideas" are taken somewhat seriously today - creating an awareness that there really is a "different way of developing software." Agile has also allowed us to attempt to tackle different problems, because agile allows us to "explore a path to a solution instead of pre-conceiving the solution before we start."

The points for Agile failing include the fact that it has been seriously oversold, there are no criteria for saying 'this is Agile and this is not,' so everything can be Agile. Michael Mah, citing data from his company and from Cutter, suggests that only 1/3 of all "agile projects" really are. More troubling, 2/3 of the 'agile projects' have higher defect rates than traditional projects - they are clearly not delivering on the promise of Agile. Bob Martin notes that "mainstream merely means not newsworthy" even though most of the agile practices are still controversial, "religious and polarizing on the ground."

Some of the more interesting comments about Agile 'losing its way' focused on the fact that too many proponents have failed to realize what is really important and what is not: "Debates about Kanban versus Scrum are simply irrelevant, Agile is a concept not a specific practice or set of practices;" and, "Agile is about learning, not memorizing rituals and practices."

Almost everyone expects that Agile is in for a severe backlash.

Is Software Development a profession? And, conversely, are software developers, professionals?

No and No! There is a nascent profession perhaps, but it is not there yet. Certainly there are some developers who exemplify the kind of standards and skills that we associate with professionals and are certainly deserving of the respect we accord a professional class, but most, unfortunately are not.

It was very interesting to note that most of the arguments against 'professionalism' parallel a debate about whether or not Management is a profession (see the most recent edition of the Harvard Business Review). As David Hussman pointed out, "software developers have nothing to profess;" there is no fundamental creed, like the Physicians 'do no harm,' no set of professional standards and ethics, and no authority to act as a gatekeeper to the profession. Software development also lacks a "consistent body of agreed upon knowledge - like medicine or law - and the true "professionals" achieved that status via experience and learning over time, not a book and university education.

The most remarkable observation, shared by all the respondents, was that the single biggest barrier to professionalism was the inability of practitioners to say NO! No you cannot have that, no that is not possible, no that is not ethical.

 Is the possession of multiple certifications a prerequisite to becoming a professional?

"For God’s sake no!" "Absolutely not!" "There is no correlation between existing certifications and reality, Scrum Master is laughable (it means you paid a fee), most others are a crock." The blunt and emotional responses made it quite clear that none of our respondents saw any correlation between certification and professionalism. Most noted that some kind of truly professional licensing, akin to doctors, with an extended period of experience (e.g. residency) might be useful in defining a professional group, but even that was problematic because so much of what a software developer needs to know is not reducible to a college curriculum.

Will the Software Craftsmanship movement have a significant impact on the issue of professionalism?

"I hope so," said Bob Martin, perhaps one of the most notable and venerable champions of Software Craftsmanship, "it is certainly raising awareness and is a step on the right path; it acknowledges that both art and science are essential for what we do." Most of the other respondents were hopeful, but very reserved. "A bigger change is needed and [SC] is just a push in the right direction." "The recognition of a need for apprenticeship will be one of the most important contributions of this effort." "Not sure about SC, it tends to be a rebranding of XP practices with some shame attached." "SC is just another cycle of the same old issue of better preparation - an artifact of the new generation of programmers that do not have the skills and experience of the old guys and so they are seeking a way to 'catch up.'" Perhaps the biggest reservation about Software Craftsmanship is the fact that it is almost totally programmer-centric and ignores the much broader issues of collaboration, management, analysis, and design.

Name Three books, that every software developer "Must Read!

• Freakonomics, by Steven Levitt and Stephen J. Dubner
• The Checklist Manifesto, by Atul Gawanda
• The Black Swan by Nassim Nicholas Taleb
• Clean Code by Dean Wampler
• Sketching the User Experience, by Bill Buxton
• A Pattern Language, by Christopher Alexander
• Peopleware, by Tom DeMarco and Timothy Lister
• Design Patterns, by Gamma, Helm, Johnson, and Vlissides
• Refactoring, by Fowler, Beck, Brant, and Opdyke
• Structure and Interpretation of Computer Programs, by Abelson and Sussman
• Design of Everyday Things, by Donald A. Norman
• Agile Project Management, by James A. Highsmith
• Stand Back and Deliver, by Pollyanna Pixton
• Orbiting the Giant Hairball, by Gordon MacKenzie
• Pattern Hatching, by John Vlissides
• Notes on the Synthesis of Form, by Christopher Alexander
• Object Design and Designing Object-Oriented Software, by Rebecca Wirfs-Brock
• Extreme Programming Explained, by Kent Beck
• Manage your Project Portfolio, by Johanna Rothman
• Flight of the Creative Class, by Richard Florida
• The Global Brain Awakens, by Peter Russell
• Difficult Conversations, by Stone, Patton, Heen, and Fisher
• Anything by Robert Heinlein
• Anything by Jerry Weinberg
• Classical Analysis texts by Yourdon, Constantine, De Marco, and Jackson

Name two tools with which a software developer must be proficient.

Whiteboard and Post-It Notes / index cards were the overwhelming responses. A refactoring browser, one of the X-Unit testing tools, and a continuous integration tool were the only software tools that most felt were useful; with a source control tool and a code coverage tool being mentioned for programmers. None of the process or management tools were deemed of value except, maybe, in the case of geographically distributed teams.

Are BS, MS, MIS, Ph.D. graduates from Computer Science, Software Engineering, or MIS programs employable?

"Yes, kind of." "Kids right out of school have the greatest potential, just like young mathematicians, but they do need how to work for a living." The consensus answer: school is too limited and too often stresses the wrong skills. Graduates need the kind of real world experience and knowledge that could only come from an apprenticeship or, sometimes, a strong internship program. Notably absent from most curricula - team and project experience, working with users, analysis and design skills, negotiation, and best practices.

Are there any aspects of software development that cannot be off-shored?

Yes, anything requiring an understanding of context, product ideation, use analysis, usability, culture, or understanding of business value. Only commodity work can be off-shored. Anything requiring high-bandwidth communication and anything where you are relying on creativity or innovation.

In addition to QCON - what two conferences are "Must Attend!"

The value of large conferences has rapidly eroded, none really stand out and most mistake crowds for community. There are a lot of small regional conferences and gatherings where you can actually get involved in community building - and making a contribution to that community. You need to 'find your tribe' and sit with them. QCon is one of the few conferences that has actually figured out what it is and who it is for. There are too many other opportunities for the younger generation to network, share, and collaborate - the era of the conference may be coming to an end, except for the specialized and attendance capped conferences like the AYE conference started by Jerry Weinberg.

Is the practice of software development in Europe, Asia, and the US different in any important way? And are there lessons to be learned from each other?

Most of the respondents avoided answering this question, mostly because a lack of deep experience working on other continents. Everyone agreed that we all need a better understanding of culture and how culture affects what we do, how we do it, and what impact it will have when we deploy it.

In the 80's we saw the 'mother of all language wars' between Smalltalk and C++. Today we are seeing echoes of that conflict with object (Java this time) and functional languages. Do programming languages really matter?

"No, just because you speak Spanish, it does mean you can write a good book." The general consensus was, because programming languages are all Turing machines and therefore essentially equivalent, they do not ultimately matter. However, different languages allow you to express yourself easier and more clearly so, "if you have a book to write," you might find it easier to do so in one language than another. There is also a weak version of the Sapir-Whorf Hypothesis at play - you can think different things, and are encouraged to think differently, given one language over another. The ultimate issue is your ability to think about and conceptualize 'something to say' and once you have done that, find the language that allows you to say it most directly and elegantly.