BT

State of the Practice - 2010

by Dave West on Jun 23, 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.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Missing book from the list of "Must Read" by jean-simon Larochelle

Although every programmer will come up with a missing book I think one book that is missing from the list is Steve McConnell's "Code Complete". This is really a classic and a "Must Read". While the two books are not exactly equivalent I consider "Code Complete" to be superior to Robert Martin's "Clean Code" and if I was to read only one I would select "Code Complete".

Out of touch by John L

At least one of us is out of touch. Maybe it's me, but I don't think so.

Agile is mainstream? I'm in a waterfall group at the moment. The last group I was in had a waterfall manager and a bunch of cowboys who called themselves "agile". When a small number of us wanted to do real agile (user stories, backlog, fixed-time-period sprints), that got rained on. The group before that was all offshore, except for maybe three of us, and I have to say the offshore team did not really understand agile.

Formal degrees in CS interfere with employability? Wow, it's worse than I thought. I guess that explains why so many people are simply not on board with OO design and strong static typing, and everybody wants to put functionality behind the OK click handler or in a stored proc in the database. And they think "code reuse" is copy and paste. Yay, kids fresh out of school!

*Three* must-read books followed by non-prioritized list of 25 bullets, including "anything by Heinlein"? Really? Heinlein is a must-read for software developers? (Yes, I've read a bunch of Heinlein.)

"Today it's all about the Cloud"? Really? How about: today it's all about maintaining/adding features to code written ten years and two technologies ago?

You book and magazine article authors are living on the leading edge, but not most of us in the trenches. I'd love to know what it's like working at eBay. Or Sears, Roebuck and Co.

Is Software Engineering a profession? by Adam Nemeth

Yes, I think it is a profession.

We have a code of ethics (in fact, multiple ones), at least at my alma mater (BUTE), every freshman is told to use IEEE code of ethics, and oathed for at the opening ceremony:

www.ieee.org/membership_services/membership/eth...

We have a common base of knowledge. Unfortunately to some, it does not include TDD as basis, but it does include automated testing; it also includes the process of specification-design-implementation-testing-deployment (yes, testing at last currently). Most of these can be found at SEEK (educational knowledge) or SWEBOK (body of knowledge). Most european universities adhere to this.

It does mean for example, that you try to do no harm for the community you're working for (and, as an engineer, your product will be used mostly by a community rather than a single user). By large scale, you cannot do harm to the community of people, the humanity. It's not as obvious at the small scale sometimes.

Yes, there's no authority which makes sure you align yourself to these: it rather depends on what to use from your toolbox in your current situation (and even unit tests shall sometimes be dropped, like in small regexp-based vim macros).

But for hundreds of years, medicine didn't have a proper way of telling what happens inside the human body, yet still it was a profession, even if it said complete nonsense. On the other hand, houses were built before the rising of formal engineering education, and some of them still stand.

It's not a standards body, what makes a profession. Not even Unit Testing, or TDD, or whatever TLA you come up with.

It's professionals who make it.

missing books AND agility by Hal Arnold

Nice article. Pretty much mirrors the group-growth in our shop.
I'm surprised that Joshua Kerievsky's "Refactoring to Patterns" and Eric Evan's "Domain Driven Design" both 'missed' the list. I think they are indispensable.
As to the practice and craftsmanship of our trade: I'm doing a lot of interviewing for senior software engineers, and I can tell you that nearly every candidate lists 'agile' on their resumes. But what they are practicing is 'waterfall with daily stand-ups'. So I understand what the assertion that "agile is mainstream" means: Agile has become the new Waterfall!

No reality check. by Filip Perlhagen

"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."

That is bullshit in it purest form. The Agile Manifesto clearly states 12 principles: agilemanifesto.org/principles.html. In front of every one of those can principles you can put a checkbox and if you follow all 12 you are following the Agile Manifesto.

"Agile is Mainstream!" Where is the source/data to back up that wild claim?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT