| |
Back in the Day
Does anyone remember James Martin the "father" of CASE tools, RAD and Information Engineering (IE)? Unfortunately, I lived it.
- IE was way ahead of its time
- IE made too many promises
- CASE tools were no where close to matching the theory
- IE produced paper, paper, paper
- To Martin's credit, he got the ball rolling
Now there's a new kid on the block. In Wired terms, Information Engineering has so expired, Structured Design Methodology (SDM) is tired, and Agile Development is so wired. IMHO, always wired! Back in the day, there there wasn't Agile Development nor did we use terminology diatribes. We just used common sense. Here is proof positive.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Agile Principles
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity--the art of maximizing the amount of work not done--is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Why Me Likey
Now we're talking. There is finally a philosophy and a set of methodologies that focuses on the customer and marries the goal of software development and businesses goal of making and saving money. The cool thing about the Agile Manifesto is that, business people can understand it. There's no techno babble.
Now the key will be to keep the principles in context and not abused for self serving needs. Business people have to play by the same rules.
Agile and the Web
Here's a excellent article on Successful Web Development Methodologies.
Why you say? Because Martin Bauer experience shows that you have a choice of adopting an existing methodology, adapting from an existing methodology or building your own. That's right building your own. Who's to say who's Best Practices are best? Follow or lead, it's your choice.
Taking a retrospective, Lavalife was using this methodology during it's first decade or so. The philosophy was:
- Planning, planning, planning. We use to have projects planned for an entire fiscal year. Sure there were bumps in the road but at least we did it. This was achieved through strategic planning during a week long "annual meeting".
- Involving the right individuals as early as possible, i.e. getting developers to start thinking and architecting the application on paper napkins, flip charts and white boards! Huh - there's actually a term for this type of design (go figure), Low Fidelity Design.
- 99% of the project communication was performed face to face with the exception of the regional offices. I hates email, nothing more then long threads.
- The other key thing was asking, what's the minimum amount of documentation required to get a feature or product developed and to market.
- Finally, skilled, experienced, motivated, focused and hard working individuals working as a team.
The first 3 generations of the Lavalife Alum would totally agree with the Principles behind the Agile Manifesto.
However, I don't want to leave the impression that we were good or great, but we met the goal of launching money making products into the market on time or in a timely fashion.
We didn't have the budgets for all the fancy tools, we made due with what we had, our brains. We didn't care about following formal methodologies verbatim. We adopted what we needed based on what worked!. Estimating through function points. Yeah OK, maybe like never. Well, I can't say never.
These terms / formally accepted methodologies didn't exist at the time or should I say branded at the time. But for all intense and purposes we achieved success through timeboxing and Feature Driven Development (FDD). The Lavalife Co-founders, especially Ed can be credited with implementing many of these founding principles.
But the key ingredient was having Generalizing Specialist like Craig to complete the mix!!!
If I had describe the development process, it would be controlled chaos! I'd rather have this then an imposed methodology from Ernst & Young or some other "software experts" that is 10 binders thick.
I believe that to become an agile software developer that you need to move away from being a narrowly focused specialist to become more along the lines of what I like to call a generalizing specialist. A generalizing specialist is someone with one or more technical specialties who actively seeks to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas. When you get your first job as an IT professional it is often in the role of a junior programmer or junior DBA.
You will initially focus on becoming good at that role, and if you're lucky your organization will send you on training courses to pick up advanced skills in your specialty. Once you're adept at that specialty, or even when you've just reached the point of being comfortable at it, it is time to expand your horizons and learn new skills in different aspects of the software lifecycle and in your relevant business domain.
When you do this you evolve from being a specialist to being a generalizing specialist. Generalizing specialists are often referred to as craftspeople, multi–disciplinary developers, cross–functional developers, or even "renaissance developers".
The problem with specialists is that they have difficulty working together effectively with others because they don't have the background to understand the issues that the others are trying to deal with. Furthermore they are often motivated to create far more documentation than is required, when all you can do is write use cases then those use cases will end up including information that could be better recorded elsewhere, and very likely require reviews of said documentation when they provide it to other specialists. The implication is that the same piece of information will often be captured by several specialists because they're afraid that they'll lose that information.
It's quite common on projects dominated by specialists to see a business rule captured in a user interface specification, in a business rule specification, in a logical data model (LDM), in a UML class diagram, in acceptance tests, and in source code. Clearly there's a chance that the business rule will be described inconsistently let alone the obvious overhead involved with reviewing and maintaining each version of it.
A generalizing specialist will write less documentation than a specialist because they have a greater range of options available to them. Instead of having a user interface specialist capture the rule in a screen specification, the data specialist capture it in an LDM and so on the generalizing specialist will instead capture it in the most appropriate place(s). In this case that could be in the form of one or more acceptance tests as well as in the source code. In short, a generalizing specialist can choose the best artifact to to capture the information in one and one only place. The implication is that a team composed of generalizing specialists will be more effective than one composed of specialists.
A generalizing specialist is someone with a good grasp of how everything fits together. As a result they will typically have a greater understanding and appreciation of what their teammates are working on. They are willing to listen to and work with their teammates because they know that they'll likely learn something new. Specialists, on the other hand, often don't have the background to appreciate what other specialists are doing, often look down on that other work, and often aren't as willing to cooperate. Specialists, by their very nature, can become a barrier to communication within your team.
A generalizing specialist is more than just a generalist. A generalist is a jack–of–all–trades but a master of none, whereas a generalizing specialist is a jack–of–all–trades and master of a few. Big difference. A team of generalists can easily flounder because none of them have the skills to get things done.
In many ways a generalizing specialist is simply a software craftsperson (McBreen 2001). The reason why I don't use the term 'software craftsperson' is that it is a loaded one that is likely to turn off a large number of traditional developers that prefer something along the lines of "software engineer ". I believe that 'generalizing specialist' is more palatable.
In short, my experience is that generalizing specialists are much more effective than either specialists or generalists. The best developers are generalizing specialists, or at least actively are trying to become so. There is still room for specialists within your IT department, they can often act as internal consultants to your development teams, but as IT departments become more agile I suspect that we will see fewer specialists surviving over time.
Paired Programming
I agree with the goals and practices of Extreme Programming (XP). But are you guys on glue? Sorry people, I don't totally agree with having Paired Programmers. I understand the benefits from a development standpoint, in regards to more efficient code, less bugs aka unwanted features and minimizing code reviews.
For companies that can afford paired programmers fine. What about medium and small businesses who don't have the financial means?
Maybe the context should be that pair programmers is based on the criticality of the application. For example, if you're building the guidance system for the Space Shuttle, then yes. Now for web sites, nopers.
Based on my experience and those of friends, my hypothesis is that the underlying crux of the matter is that companies aren't willing or don't have the ability or the skills to hire and pay highly qualified developers.
Reality
The true fallacy is having developers estimate the development time based on scant requirements and then expecting it to be the deadline. The result is endless hours of OT. I use to double estimates because you just don't know all the facts. I know someone who use to triple the number. Sorry, I can't give away his name. So spend the time in gathering the facts and then provide a more realistic estimate. It's then up to the business to decide what to bite off.
Many out there have resorted to function points to provide better estimates. You won't catch me using function points. Why? Because the project would never get done!!! Well, it might but the business opportunity definitely would have been missed.
When moving from requirements to design, there is an explosion of "derived requirements" (the requirements for a particular design solution) caused by the complexity of the solution process. The list of these design requirements is often 50 times longer than the list of original requirements.
If you're still interested, read Extreme Programming and the Capability Maturity Model by Ronald Jeffries and Portrait Of An Agile Development Process by Jake Lawlor.
In the End
When all is said and done, it comes down to the quality of the people and the value of hiring good programmers. Anyway, here's how I see it, Diet Lite instead of paper heavy and bureaucracy. More precisely, light for non-human critical applications and heavy for human critical applications. OK, I've found a kindred soul in Martin Fowler. Here's his article, The New Methodology.
How do you preserve creativity and keep it from being overtaken by bureaucratic process? ... Great designs come from great designers and not from great processes. ...Make sure that we recruit great designers... grow them by systematic training programs... cherish them... mold them into a team
Tom Demarco and Timothy Lister, Peopleware - February 1, 1999
|
|
|
|
Previous
