Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Dr. Dobb's Agile Update 08/09

Scott Ambler is Chief Methodologist/Agile and SOA for IBM Rational. He can be contacted at [email protected] blog.

In This Issue

  • Do Programmers Really Follow Development Guidelines?
  • Take the "State of the IT Union" Survey and potentially win a copy of "Real-Time Agility: The Harmony/ESW Method for Real-Time and Embedded Systems Development" by Bruce Douglass
  • Hot Links

Do Programmers Really Follow Development Guidelines?

In the June, 2009 Dr. Dobb's Agile Update, and in Jon Erickson's blog, we invited you to participate in the June/July 2009 edition of my "State of the IT Union" survey, one of an ongoing series of surveys which explore what IT professionals are actually doing in practice. In addition to project management practices, discussed in last month's Dr. Dobb's Agile Update, the survey also explored issues pertaining to governing software development projects. The good news is that governance activities appear to be succeeding in some organizations, but unfortunately as an industry we've still got a long way to go.

IT and systems engineering governance establishes chains of responsibility, authority and communication in support of the overall enterprise goals and strategy. It also establishes measurements, policies, standards and control mechanisms to enable people to carry out their roles and responsibilities effectively. Development governance is an important subset of IT and system engineering governance, the scope of which covers the steering of software and system development projects. The survey explored the use of guidelines by development teams and how effective people found their IT governance programs.

When it came to coding conventions, 59% of respondents indicated that their organization has enterprise-wide coding conventions. However, just because the conventions exist doesn't mean that people are actually following them. For example, of the respondents who indicated that they have enterprise-level coding guidelines, 17% indicated that developers were more likely to follow their own programming conventions anyway, 51% of them indicated that it was more likely for developers to follow project-specific conventions, and the remaining 32% to actually follow the enterprise conventions. Although it's good that the majority of developers were following some sort of coding conventions, and presumably writing more consistent code as a result, there is still a long way to go. When enterprise-level coding guidelines are followed by all developers you reduce your organization's overall maintenance costs as the result of increased code consistency, you make it easier for developers to share code (promoting both collective ownership and reuse), and you make it easier for developers to move between teams. Of the remaining 41% of respondents, the survey found that 32% had not considered enterprise conventions and that 44% hoped to put them in place one day (everyone else wasn't sure if they had coding conventions at all).

When it came to enterprise-wide user interface(UI)/usability conventions the numbers weren't as good. A minority of respondents, 47%, indicated that their organizations had such conventions. Of that group, 11% were following developer-specific conventions, 43% said it was common to have project-level conventions, and 47% actually followed the enterprise-level conventions. Of the remaining 53%, 45% had not considered enterprise conventions, 38% hope to put them in place one day, and the rest wasn't sure if they even had UI/usability conventions.

I suspect that fewer organizations had UI/usability guidelines compared to coding guidelines because developers have a greater interest in technical issues as compared to more "artistic" or "softer" issues. This may also be a plausible explanation for why developers are more likely to follow enterprise-level UI conventions when they do exist: because developers are not as interested in UI issues they're less likely to have strong opinions about UI guidelines and therefore less likely to create their own.

The survey also revealed a similar pattern with enterprise-wide data conventions, in this case 51% of respondents indicated that they have some. Of the 51%, 14% indicated that it was more common for developers to follow their own conventions, 37% indicated that project-level data conventions were more common, and 49% indicated that developers followed the enterprise-level data conventions. Of the remaining 49% of respondents, 43% had not considered enterprise conventions, 36% hoped to put them in place one day, and the rest weren't sure if they existed. I also suspect that data conventions suffer from the same challenges which apply to UI/usability conventions, something to be explored in future surveys.

The problem may go even deeper. The survey also explored the perception regarding relationship between development teams and their organization's data group (unfortunately I didn't explore the relationship between developers and their UI/usability group). The survey found that 32% of respondents had no data group at all (larger organizations were more likely to have one than smaller organizations). When it came to the effectiveness of the data group, the remaining 68% of respondents provided mixed results. 10% of them indicated that it was too early to tell how effective the data group is and 50% found them to be effective. Unfortunately, 29% indicated that development teams prefer not to work with their organization's data groups but are forced to do so and 10% try to avoid them whenever possible. The ongoing challenges between data professionals and developers may be affecting the likelihood that development teams will follow corporate data conventions, thereby contributing to data quality problems.

One issue that we don't have very good industry numbers on is how effective IT governance programs actually are in practice. So, I decided to scratch the surface of this issue in this survey. What I found was that 36% indicated that they had no IT governance program at all, 44% had one, and 20% didn't know if one was in place or not (potentially an indication that governance programs aren't marketed well internally). Of the 44% of respondents working in organizations with IT governance programs, 14% indicated that it was too early to tell how effective the program was, 18% indicated that their IT governance program generally helps, 43% indicated that it was neither helpful nor harmful, and 25% believed that it was generally harmful. Apparently there's significant room for improvement in the way that organizations approach IT governance.

There were only 125 respondents to this survey, so to be conservative we should consider these results indicative of trends but not the final word. Having said that, none of the results seem unreasonable. For everyone who filled out the survey, thank you very much. For those who didn't fill out the survey, please consider doing so in the future. As a community we have an opportunity to find out what is actually happening in IT departments around the world, and based on this knowledge perhaps we can change things for the better. I keep these surveys as short as possible and as you can see the potential to get meaningful results is clearly there.

Survey: State of the IT Union

We invite you to participate the September 2009 edition of Scott Ambler's State of the IT Union Survey. The goal of this ongoing survey series is to find out what IT professionals are actually doing in practice. There are 15 questions on 3 pages in this survey, it should take you less than 5 minutes to complete, and your privacy will be completely protected.

At the end of the survey you will be given the chance to be entered into a draw for one of five copies of Real-Time Agility: The Harmony/ESW Method for Real-Time and Embedded Systems Development, by Bruce Douglass (Addison Wesley, June 2009).

The results of this survey will be summarized in a forthcoming newsletter by Scott Ambler. Furthermore, this is an open survey, so the source data (without identifying information to protect your privacy), a summary slide deck, and the original source questions will be posted at www.ambysoft.com/surveys/ so that others may analyze the data for their own purposes. Data from previous surveys have been used by university students and professors for their research papers, and hopefully the same will be true of the data from this survey. The results from several other surveys are already posted there, so please feel free to take advantage of this resource.

Hot Links

The results from the July 2009 State of the IT Union Survey are now online.

In Agile and Traditional Governance (Dr. Dobb's Agile Update, February 2009) I argue that effective governance is very important to the success of software development teams, something that is true regardless of your development paradigm. Although traditional approaches to governance may work well for traditional development teams, and please note the use of the word "may", they often prove detrimental to agile development teams. When adopting agile approaches within your organization I highly suggest that you take the time to rethink your approach to IT governance.

Why Developers Should Demand Effective IT Governance (Yet Have Little Hope of Getting It) examines the issues surrounding traditional strategies for IT governance and argues for leaner, more agile strategies.

Lean Development Governance by myself and Per Kroll overviews a collection of practice for effective governance of development projects.

My blog posting Scaling Agile with Risk-Based Milestones shows how to apply the Unified Process's milestone review points to effectively govern agile projects.

The Surveys Exploring the Current State of Information Technology Practices page links to the results of all the Dr. Dobb's surveys which I've run over the years.

The details of this survey, including the original questions, source data, and a summary slide deck, will be posted at State of the IT Union: July 2009 in late August 2009.

My [email protected] blog discusses strategies for adopting and applying agile strategies in the complex environments.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.