Slashdot Mirror

I would wonder if this is part of a larger conspiracy to wipe out the large concentration of Agile 2012 Conference attendees who stormed the city this week.

Basically this is the slope of the line of estimated remaining work over a fixed timebox (such as an iteration or sprint). It's based on an application of the Central Limit Theorem and therefore it requires a few things to be in place in order to be accurate. I'm hoping to do a presentation on Commitment Velocity at the Agile 2010 conference in Nashville (link is to my session proposal).

I'm flattered by your comments, but I'm afraid I'm not even remotely qualified to present at a conference, particularly not one on Agile ideas. I wish you luck, though. It's a bit far from the UK to come for a visit, so have a beer for me while you're there. :-)

I understand, but you should definitely think about it.

Almost all of the presenters are people working in the field; few are full-time "experts". And by definition, the "Questioning Agile" is meant to draw in outside views. If you're already mentoring junior developers and can present to 20-30 people, then I'm sure you're as qualified as the average presenter. The rest is preparation, and the year until Agile 2009 gives you plenty of time to develop your thesis, to collect evidence of the problem, and to deliver a couple of practice talks to local user groups or other interested parties.

Don't forget there are also a variety of European Agile get-togethers, from the London Extreme Tuesday Club to the large annual conference. You can keep an eye out for ones in your area on the Agile Alliance events page.

But I'm serious that we're always looking for outside views. the Agile 2008 closing keynote is by Alan Cooper, who for years publicly maintained that we were all dangerous lunatics, inimical to good software development everywhere. He's now moderated his position a little, but I know he's coming to challenge a variety of our notions, and I'm looking forward to it.

And yes, I'll definitely hoist a beer in your lack of name. :-)

I'd say Rational Rose is what they sell you when you buy into RUP, not the other way around. "Like our process? Buy the matching software suite!" And don't forget Websphere Developer, only $2650 per seat. Nevermind it's based on Eclipse which is free and better maintained.

I've heard rumor that my current client paid about $500,000 for Rational kool-aid. A lot of good it does them too. Most of the packages are real albatrosses! Gigantic, unweildly, and obstructive. We basically just use ClearCase and ClearQuest for the equivalent of what you could do with Subversion and Bugzilla. I can't find one person in this company that uses these tools because it makes them more effective.

Yes, RUP is a step up from waterfall. But for most companies that "implement" RUP it's waterfall by another name. Anyone who's smart enough to use RUP properly probably isn't using RUP because they know there's something better .

And yes, IBM will be sending us their "consultants" for the next "iteration" of development.

I have successfully used Test Driven Development in several of my projects and it is a uniquely satisfying experience. Writing test cases before writing the code then completing each test case one after another in steady progression gives a constant stream of small victories. It also means you can run all test cases at a later time and see that "yep, everything still works" or "doh! that change just broke 10 things I already had working."

There are several other benefits to writing tests first as well. The experts in the link above explain it all better than I could, I'm sure.

Many open source projects are taking this approach already and usually boast the number of unit tests along with the lines of code included in the distribution. Anyone can type in "build test" for example and it will show the program run and pass some odd thousand tests.

Is it time for the Kernel to embrace this methodology? I certainly think it is a genuine best practice. But is it applicable to OS development as well? I don't see any reason why it wouldn't be, but I am not a kernel developer myself.

Disclaimer: I do work for Microsoft, though I don't agree with everything they do. I'm not a game developer, though I aspire to be one, and have been following XNA closely.

XNA Studio will speed development time and decrease development costs by delivering an advanced build framework and a suite on integrated tools to solve common production challenges.
Sounds fine to me. XNA has a toolset that allows you to configure/optimize projects, with tools thrown in tha address problems that frequently come up in production environments.

...and allows programmers to leverage the skills...
Developers used to Visual Studio can get started faster. Ever try to switch from Paint Shop Pro to Photoshop to Gimp? 3D Studio Max to Maya to Lightwave? This is not a toothless problem.

...development processes and will ship with process support for Agile Software Development.
So the tools support the Agile Software Development process. Why, specifically, is Test-Driven-Design, eXtreme Programming, Feature Driven Development, and other tenants bad? Besides their names. :)

Our focus with XNA studio is to deliver the incredible productivity and collaboration services... ...integrated pipeline to streamline data and content
Again, why is this bad? The whole point is that different groups aren't working together quickly enough.

I honestly don't see what was wrong with these sound bites. Remember... managers are the ones that make the purchasing decisions... I don't blame him for using a bit of management lingo (especially when the words concisely convey the intent of XNA).

How about some other sound bites?

...We didn't invent all the ideas going into XNA studio; we talked to the community...

...We only succeed if we solve game development problems and make developers more productive...

...XNA Studio is for all members of the game production team from artists to designers to programmers to producers to QA...

...One of the main pieces of work we are doing is making the collaborative services available in a form that is natural to these other roles and it could take many forms: small stand alone clients, direct integration with the major DCC tools etc...

Disclaimer: I do work for Microsoft, though I don't agree with everything they do. I'm not a game developer, though I aspire to be one, and have been following XNA closely.

XNA Studio will speed development time and decrease development costs by delivering an advanced build framework and a suite on integrated tools to solve common production challenges.
Sounds fine to me. XNA has a toolset that allows you to configure/optimize projects, with tools thrown in tha address problems that frequently come up in production environments.

...and allows programmers to leverage the skills...
Developers used to Visual Studio can get started faster. Ever try to switch from Paint Shop Pro to Photoshop to Gimp? 3D Studio Max to Maya to Lightwave? This is not a toothless problem.

...development processes and will ship with process support for Agile Software Development.
So the tools support the Agile Software Development process. Why, specifically, is Test-Driven-Design, eXtreme Programming, Feature Driven Development, and other tenants bad? Besides their names. :)

Our focus with XNA studio is to deliver the incredible productivity and collaboration services... ...integrated pipeline to streamline data and content
Again, why is this bad? The whole point is that different groups aren't working together quickly enough.

I honestly don't see what was wrong with these sound bites. Remember... managers are the ones that make the purchasing decisions... I don't blame him for using a bit of management lingo (especially when the words concisely convey the intent of XNA).

How about some other sound bites?

...We didn't invent all the ideas going into XNA studio; we talked to the community...

...We only succeed if we solve game development problems and make developers more productive...

...XNA Studio is for all members of the game production team from artists to designers to programmers to producers to QA...

...One of the main pieces of work we are doing is making the collaborative services available in a form that is natural to these other roles and it could take many forms: small stand alone clients, direct integration with the major DCC tools etc...

Disclaimer: I do work for Microsoft, though I don't agree with everything they do. I'm not a game developer, though I aspire to be one, and have been following XNA closely.

XNA Studio will speed development time and decrease development costs by delivering an advanced build framework and a suite on integrated tools to solve common production challenges.
Sounds fine to me. XNA has a toolset that allows you to configure/optimize projects, with tools thrown in tha address problems that frequently come up in production environments.

...and allows programmers to leverage the skills...
Developers used to Visual Studio can get started faster. Ever try to switch from Paint Shop Pro to Photoshop to Gimp? 3D Studio Max to Maya to Lightwave? This is not a toothless problem.

...development processes and will ship with process support for Agile Software Development.
So the tools support the Agile Software Development process. Why, specifically, is Test-Driven-Design, eXtreme Programming, Feature Driven Development, and other tenants bad? Besides their names. :)

Our focus with XNA studio is to deliver the incredible productivity and collaboration services... ...integrated pipeline to streamline data and content
Again, why is this bad? The whole point is that different groups aren't working together quickly enough.

I honestly don't see what was wrong with these sound bites. Remember... managers are the ones that make the purchasing decisions... I don't blame him for using a bit of management lingo (especially when the words concisely convey the intent of XNA).

How about some other sound bites?

...We didn't invent all the ideas going into XNA studio; we talked to the community...

...We only succeed if we solve game development problems and make developers more productive...

...XNA Studio is for all members of the game production team from artists to designers to programmers to producers to QA...

...One of the main pieces of work we are doing is making the collaborative services available in a form that is natural to these other roles and it could take many forms: small stand alone clients, direct integration with the major DCC tools etc...

Disclaimer: I do work for Microsoft, though I don't agree with everything they do. I'm not a game developer, though I aspire to be one, and have been following XNA closely.

XNA Studio will speed development time and decrease development costs by delivering an advanced build framework and a suite on integrated tools to solve common production challenges.
Sounds fine to me. XNA has a toolset that allows you to configure/optimize projects, with tools thrown in tha address problems that frequently come up in production environments.

...and allows programmers to leverage the skills...
Developers used to Visual Studio can get started faster. Ever try to switch from Paint Shop Pro to Photoshop to Gimp? 3D Studio Max to Maya to Lightwave? This is not a toothless problem.

...development processes and will ship with process support for Agile Software Development.
So the tools support the Agile Software Development process. Why, specifically, is Test-Driven-Design, eXtreme Programming, Feature Driven Development, and other tenants bad? Besides their names. :)

Our focus with XNA studio is to deliver the incredible productivity and collaboration services... ...integrated pipeline to streamline data and content
Again, why is this bad? The whole point is that different groups aren't working together quickly enough.

I honestly don't see what was wrong with these sound bites. Remember... managers are the ones that make the purchasing decisions... I don't blame him for using a bit of management lingo (especially when the words concisely convey the intent of XNA).

How about some other sound bites?

...We didn't invent all the ideas going into XNA studio; we talked to the community...

...We only succeed if we solve game development problems and make developers more productive...

...XNA Studio is for all members of the game production team from artists to designers to programmers to producers to QA...

...One of the main pieces of work we are doing is making the collaborative services available in a form that is natural to these other roles and it could take many forms: small stand alone clients, direct integration with the major DCC tools etc...

Damn Slashcode and its inability to edit or augment comments!

that is being addressed partly by the research and practice of agile methodologies. The idea is to change the focus of software development to a new set of principles (for example favoring running software over documentation).

There is also a problem with the way that many managers and business people view software creation as a construction or engineering process. I wrote a paper about this: "The Software Construction Analogy is Broken". The summary is that software has so many attributes that are unlike physical things that its creation cannot be accurately mapped to the creation of buildings. For example, the economics of distribution are completely different: a building cannot generally be moved after it is constructed, yet software can not only be moved, but also can be duplicated for almost zero cost.

Ultimately, I think that software creation is actually the creation of completely new media of communication. Every program created defines a new set of communication interactions that didn't exist before. We don't really have any "science" for that.

I highly recommend you read about either Extreme Programming or Agile Software. Both of these schools of thought have come to the realization that you never want a big design up front. Keep your design as absolutely simple, dumb, and difficult to screw up as possible. Yes, those all go together. It's the ONLY way to design stable, quality software. No object-database wrapping engines, no XML Soap Servers, massive new framework. If you can possibly get by with some PHP scripts accessing a MySQL database in a weeks worth of time to get 50% the functionality, do it!

Let me say this again: If there is any way to make it simpler, do it. Stop whining, just make it simple.

Refactor your code later, only when needed. By keeping your design simple, you'll save time and those defects you were worring about will be minimal. Testing should be done either through unit tests or simple procedures.

And here's the most important part: give them WEEKLY releases. Never "postpone" a release. This lets them know where you are at in the project, and there will be no surprised or misleading estimates or anything. Never give estimates further out than a week, and always break down tasts into smaller tasks that will take less than a week.

And stop your bitching about not having enough time for a "top bottom" design. Top bottom designs are categorical failures.

You can get almost all of that bandwidth in a phone call. "Tele"-commuting means tele"-communications. Whiteboarding is good too.

Some, perhaps. But nothing close to all.

I work in the style of various Agile methods, including the unfortunately named Extreme Programming. This involves close team development.

One great benefit is intentional communication. Turning to the guy at the next desk to ask a question is still an order of magnitude easier than even the shiniest phone. And the bandwidth is still a lot higher; on the phone you lose expression and posture, to say nothing of the ability to hand you something.

But just as important is the unintentional communication. If the pair next to me is having trouble with something that I know about, then I can just pipe up. If I'm making a decision that affects them, they can put their two cents in without me having to call a meeting.

Sitting in the same room with my team gives me a great deal of information about the state of the project for free. Getting the same info by telephone or email is much, much harder.

If someone is not producing good documentation, they are a long-term drain on the organization and should be dumped. Just a rule of thumb, of course, but an important one.

Alternatively, perhaps it's the organization that develops in a way that requires a lot of paperwork that is a long-term drain and should be dumped.

Documentation is a method of communication. We communicate so we can develop with speed and accuracy. But documentation isn't the only way to do that, or even the best one.

When documentation is necessary, I use it. (And as a published writer, I even think it's fun.) But it's never my first choice.

The fundamental question seems to be :
Do processes make better software
I've been involved with a lot of software projects (though never contributed much to Open Source...), and I have never seen a single project that was succesful because it followed a process. Nevertheless, whenever a project runs into trouble, the first call is usually for "more/better process !!". So let's look at this in more detail.

Succesful projects seem to grow their own process. The process seems to be simple, and often appears to be way less than you would expect, and rely heavily on interpersonal communication rather than documents and frameworks. There's usual a small core of "gatekeepers" who set the technical and philosophical tone for the project. The Linux kernel is a good example.

I am very worried about people using phrases like "mature process", "industry standard" etc. - in my experience, this often refers to the Rational Unified Process or the Software Engineering Institute's Capability Maturity Model. Both are laudable and when I go on holiday, I really want the airplane's control systems to be written using such processes. However, for many projects, the burden of bureaucracy is inappropriate (yes, I know you can tailor the RUP to suit your needs, but it contains over 140 different deliverables, none of which appears to be code). The training required to bring developers up to speed with these processes is significant, and usually expensive.

Instead, I'd look at the Agile methodologies at Agile Alliance website. The "Crystal" methodologies are especially interesting because they encourage you to actively choose the processes your project needs based on a variety of parameters - size, risk etc.

Having said that, I think a lot of the problems addressed are real - I think they get solved by people, not processes though.

There's no intended implication that Cooper can't deal with programming in the real world, just that his view of organizational change isn't consistent with the Extreme Programming approach. If we could all pick and choose from a variety of organizations that are not dysfunctional in one way or another, or if as software engineers we were able to involve ourselves and influence organizational change in the way Interaction Design espouses, we would be fine.

Cooper's core proposal, when you get right down to it, is reasonable except for the part about requiring the organization to be able to plan up front for things that will change.

To view XP as an abdication that "papers over the cracks" is to discredit the motivations of programmers -- both staff and contract. Extreme Programmers desire to find a way to achieve business goals within real-world constraints, yet also include quality, or "excellence" in development. But the philosophical angle is perhaps best expressed by The Manifesto for Agile Software Development

XP is actually notable for its lack of "mumbo-jumbo CS-degree bullshit" -- it was developed and refined by development teams in the field (of industry and cosumer-related IT, not building space shuttles or cruise missiles, like so many other methodologies).

XP is one of a series of methodologies called "lightweight," or, more recently, "agile." A good starting point for reading about it would be the book Extreme Programming Explained by Kent Beck. (Sorry, no ISBN, look it up somewhere.) You will find it much smaller, simpler, and more informative than most books on the subject. You can also check out their website)

There are actually a lot of other methodologies besides XP that are taking this approach -- you can find a lot of links and a statement of shared values at the Agile Alliance website.

phil

1. The requirements were fully understood and detailed ahead of time
2. The biggest technical risks were understood ahead of time

• A better attempt at understanding requirements and technical risk than armchair analysis
• An actual deliverable that, if you are lucky, might just be valuable to the customer

That's why the open source rule of "release early, release often" is the proper way of doing things in commercial software as well. The emphasis on planning and control makes the difficulty of software development worse that it could be, because it focuses effort on nearly meaningless exercises (business and technical analysis) that don't uncover real risks nearly so efficiently as building working software.

See the agile software development movement for more.

I don't know about the rest of slashdotters, but I think the whole team-approach that's supposed to be the new "paradigm" (gah! there's that word again!) is a bunch of hooey. [...] Every person is unique, and some people just have a knack for certain things.

You're right about individuality, but you're wrong about the "new team approach". I've recently come back with OOPSLA, which showcased many of these new methodologies. If anything, they're a reaction agains "plug-compatible programmers" and document-heavy processes; they acknowlege that individual talents and perspectives matter more than following procedure.

But they also point out that effective software development requires effective communication and coordination among all team members. In agile methodologies long hair, anime t-shirts, and Spawn action figures arrayed on a desk are not a problem. Vampire hours, persistently rude behavior, and a disdain for the team's coding standard are.

Pick up Cockburn's "Agile Software Development", or Beck's "Extreme Programming Explained", or simply browse the Agile Alliance website. Then compare those ideas to the standard IT shop. These guys are the rebels. (What!? No PERT Charts? No spec documents?)