Agile Software Development
This holds all posts on software development process as well as other non-technical development related material.
This page has been moved to
CodeBetter.Com. Please update your links accordingly. The new post URL is:
http://codebetter.com/blogs/darrell.norton/archive/2004/03/23/9780.aspx
I’ve been exploring various facets of XP lately because I think it has a lot to offer the practice of software development. I’ve recently done pair programming, dealt with something akin to an onsite customer, and done plenty of testing with NUnit.
One issue that I’ve noticed, however, is that XP assumes skilled developers. By skilled I mean knowledgeable of various technical issues, good at interpersonal communication skills (not something developers are noted for), experienced in the art of software development, and motivated to improve themselves, among other qualities.
Surely most of the initial adopters of XP were the grizzled veteran coders, the ones that eat pointers for breakfast and deliver by lunch. Most of these programmers had been down the path of increasing process, only to find more process and less actual development. And none of it helped improve anything. IT projects continued to fail regularly, either by being late, being over budget, under-delivering, or delivering what was specified but which failed miserably when actually used in the wild.
This led to a large group of disenchanted developers, kind of like the 60’s for geeks. Geeks walked around carrying signs saying “write code, not documents!” This was a generation ripe for something as totally off-the-wall as extreme programming. It even had “extreme” in the name! How cool is that?!
The reason XP worked initially is because of the quality of the developers involved. When XP says “do not document unless you need to,” the experienced developers know that they might still need to do things like UML diagrams (agile UML, for Pete’s sake!) or ERDs or CRC cards or whatever works.
But, as XP makes the jump from the early adopters to a larger pool of developers, the average skill level is decreasing. Now when XP says “do not document unless you need to,” some of the developers think that it means to do no design period, confusing the process of design with the documentation of the design. “But,” you say, “XP says it works with skilled developers only!” Let me respond with a driving analogy. When a well-known car insurance company surveyed a group of drivers, 87 percent said that they were above average drivers. We both know that this is statistically impossible. Assuming that everyone that actually is a good driver knows it (maybe it’s printed on their insurance bill), 37 percent of the people that took this survey are dead wrong. Or, worse yet, 74 percent of the bad drivers did not know they were bad drivers (37/50 = 74%). It is the classic problem of being unskilled and unaware of it.
The issue is, how do I know what the is minimal amount of design and documentation? The short answer is “whatever will reduce overall development activity to the smallest amount.” In other words, any activity, or group of activities, that will pay for itself over the course of development. But how does someone that has not been through too much process and too much design know how little they need? It’s like the blind men and the elephant.
Of course, experience is the key. But short of that, the only solution I have come up with so far is to make sure that every developer knows the basics. By “basics” I mean things above programming language syntax but below process and methodology. Development tools such as the UML, object-oriented analysis, design, and development, ERDs, data flow diagrams, etc. You might not use some of these tools very often, but you need to know what their advantages and disadvantages are, and you need to actually have used them to do something, even if it was a "learning project."
Let me know what you think.
I brushed off my copy, it actually was dirty, thanks to my recent move, of The Design of Everyday Things and reread it over the weekend. I have the 1990 edition (white cover).
For those who have not read this wonderful usability tome, it discusses how difficult it is to use things that used to be simpler to use, before they became sophisticated. One of Donald's favorites is the telephone, to whit he devotes about 10 percent of the book's pages to. The reason for the frequency? We use telephones everyday and its uses are well known, however the usability among different designs varies wildly. Some examples reveal the book's age; this may have changed in the 2002 version, but I do not know for sure. For example, one reference is to computer passwords that must be at least six characters long and contain no words. Now, passwords must be at least eight characters containing a mix of lower and upper case letters, numbers, and some special or non-printable characters!
After reading this book the first time, I was a usability "guru," or so I thought. I walked around for the next two or three weeks pointing out bad usability design (in manufactured objects, not software) to myself or to anyone else unlucky enough to be nearby. I felt like starting my own usability company and making some serious dough pointing out such deficiencies! Of course, these were only things that were unusable to me, not necessarily everyone else.
This time is different, however, probably due to significant experience in a career as a software developer. I am struck that pointing out the usability issue is not the important part. The important part, especially as it applies to me as a software developer (WIIFM), is the asking of "why?" Asking why works really well in improving my understanding of such immense class libraries and hierarchies as the .NET Framework. Why did the designer choose to do this? Why was the API structured like it is? Are there advantages to doing things this way? How does it make developing easier on me? If it makes certain things harder to do, are there other parts of the Framework that make it easier to do those things another way? And with the ever-increasing size of .NET, I need all the help I can get!
So, unlike the slogan for the [now defunct] Bud Dry product, "why ask why?", actually ask why!
Bud Dry and its slogan are probably trademarks of Anheiser-Busch corporation.
One of Extreme Programming's practices is OnSite Customer (also see Martin Fowler's definition of OnsiteCustomer).
Although it is good if each programmer can constantly ask questions of the customer whenever they need to, it is not good if the customer has the same ability. Anytime the customer wants to ask a question, just being able to call up a developer kills that developers concentration, subsequently killing his productivity. On the other hand, if the developer is able to get an immediate answer to his question, it maximizes productivity.
The solution is to designate someone to run "interference" for the developers. Who runs this interference? In Brooks' The Mythical Man-Month, the role is assumed by the copilot, who attends all meetings, answers all technical questions, and acts as the general technical answer guru for the project. This leaves the surgeon (chief programmer) with all his time devoted to programming. In my own experience, I was the technical lead and ran interference for my team. Although I might not have made much of a contribution to our body of code directly on some days, my real accomplishment was enabling the other 8 developers to contribute 100 percent every day (8 * 100% is much more than 9 * 80%).
So what this really is is a facade for the development team. The customer is supposed to speak with one voice, and they speak to one person who will get them the answer or pass it along to a developer. Does this then break the facade? I don't think that a developer has to go through the team spokesperson to communicate with the customer, but it helps. In our case, it avoided anyone calling a developer back or stopping by our work area and standing over our shoulders for hours. I don't tend to think of email as a distraction, since you can just not check it. You might argue that most phones can have their ring disabled. Most can, but I like to keep the phone as an option for extreme development emergencies, such as when the CEO puts you on the spot in the middle of a seemingly innocent status meeting.
Devoted readers of Martin Fowler's bliki will note that in PleasingTheCustomer it says that a major source of enjoyment is direct developer-customer interaction. While I certainly agree with this, I do not think that it requires 100 percent all-day everyday direct interaction. Sometimes you just need to get things done... alone. Completed iterations, milestone deliveries, or whatever progression of steps your project goes through, are excellent times for everyone (business people and developers) to get together and party. In my experience this is usually enough, but if there needs to be more interaction to chase down a troublesome and elusive bug, then so be it. As always in agile development, people over process.
Steve Maine had a good post on Yukon and the balance of power in IT. I agree completely. The days of the strict "Admin DBA" are numbered (hopefully, anyway).
Since most software development is moving to a more collaborative model, you cannot say "I only deal with schema," or any other specific technology or niche interest. To contribute and collaborate, you must be willing to work with your team and do whatever needs doing. Sometimes I make the coffee. Is that in my job description? Is that why I have a master's degree and a bunch of Microsoft certs? No, but somebody has to do it, and since I want some I might as well make some. (Luckily we have Starbucks, so life is good!) And in the end, team members and bosses notice this stuff.
Roy Osherove posts about coding standards, referencing DotNetJunkies own blogger Mark Brown, who posted about IDesign.net's C# Coding Standards. When I was working on creating coding standards for my company, I also looked at Mike Kruger's C# coding standard, the Code Conventions for the Java Programming Language, and Scott Ambler's Coding Standards for Java.
Roy makes some good points, like make sure all employees agree with the standards, consult with everyone (a way to build consensus and buy-in), and the comment that "no one will bother adhering to a 250 page document." IDesign's coding standard is only 20 pages long, but even that is pushing it. If developers have to keep referencing the document to follow the "finer points" of coding style, it will always be rejected. Ideally, only those things which can be automatically detected (through something like FxCop) should be part of the coding standard. FxCop allows a developer to check their conformance to "standards" continuously, and it even offers explanations on how to change "offending" code and why. You can also develop your own in-house rules. I would like to caution that "Merely saying 'make it so' doesn't make it so."
As you develop a coding standard, remember that new employees will get the full hockey stick part of the learning curve, whereas you will be able to assimilate a few pieces at a time. New employees take a long time to become productive employees and salaries are the biggest expense for any consulting/software development firm, so you want to make it as easy as possible for them to get up to speed. You do not want to create additional artificial barriers that prevent employees from being productive. The key is to balance the improved readability of code with the increased learning curve for new hires. Some agile developers get along very well with a coding standard that consists of "The code must be readable and understandable at a glance."
One thing that irks me about IDesign's coding standard is that they specify spaces instead of tabs (on the whole I think the IDesign standard is very good). Visual Studio .NET can take whatever source code you give it (spaces, tabs, or spaces and tabs) and reformat it according to your preferences by simply highlighting a section and pressing Ctrl-K, Ctrl-F (or go to Edit - Advanced - Format Selection). There are other options to Tabify, Untabify, and Delete horizontal white space. Pretty much every IDE will be able to convert spaces and tabs (it is not that difficult a function), so why is this rule there? It's a waste of space and a waste of time to read.