Slashdot Mirror
You Call This Agile?
JoelonSoftware's most recent piece is about some of the fallacies in "Agile" software and some of the issues within it. We use Agile in some parts of the company, and have had success with that -- that said, there's always the peril that happens when development and other parts of the company have...miscommunication, which sounds like the problem described in Joel's piece.
This article appears to be written by Captain Obvious and his sidekick, Common Sense.
Yes, it is nice to have a dogmatic approach to programming, but ultimately it really boils down to "what course of action will have the greatest benefit to the company?" It has always been this way (even outside of software development) and it always will.
...miscommunication, which sounds like the problem described in Joel's piece
.Net for the latest report release, then into testing mode preparing another test release. All the while trying to convince my supervisor of the need for structure, project management practices, and tools to make our life easier.
Miscommunication? He's talking about context switching, which is an all too common and necessary evil in small shop development.
In any given week I can switch from architecture design to business systems analysts, back to VB6 coding for legacy app maintenance, up to
All that context switching definitely has a negative effect on my productivity. My supervisor asked me to tag tickets with time estimates when I closed them out. No biggie, but the shortest I'll tag a ticket for is 30 minutes. Originally I had said 1 hour, but my supervisor vigorously disagreed with my estimate of context switching's effect on productivity.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
He has capacity to speak his mind, as he took intensive courses on writing and expression in university, but that doesn't detract that his ideas are his and to each idea there is the opposite side that has just as many positives, if presented correclty.
Aglie development works, but only if people can be trained. Training is something that is omitted when it is decided on whatever model you want to adhere to. Remember we are all just animals and the more training we get, the better we are at it.
Agile process is based on feedback, and therefore programmer must be trained to appreciate and nuruture feedback from his practices too. Programmers need candy too, for rewards, and that candy is a feedback from wroking code. Given, if you are writing a disk driver, feedback is limited, compared to game developer, writing graphics or sound enegines. What Agile brings, is that rewards come at a steady pace, therefore propping up motivation of developer from development side of things. Disk driver developer must find his way to recieve rewards from developing driver code, perhaps thats why compensation is higher for the driver developers, because work has no immediately accessible of stimuli and chances to get negative stimuli, like corrupt disk of the user, are quite high.
If you code not for the sake of itself, I pitiy those people. But then they aren't on the slashdot.
I can write any program you want within any time limit you want provided ...
a. I don't have to support it.
b. It doesn't have to work.
Yes, that's funny, but it is not a joke. Processes are supposed to be about functionality and maintenance. A one-off app for a critical issue today doesn't need a process (except how to delete it tomorrow so it doesn't become part of they real system).
And that is where marketing and development differ. Marketing sees the opportunities in selling "support contracts" for code that was rushed out, filled with bugs and features that don't work.
Development only sees problems that they're going to have to fix. And fix today. And fix in the quickest possible way because the customers are complaining about a critical issue. And so forth.
So the various processes (and project managers) are supposed to translate/support both views. Get it out in time to make the sales, with a stated minimum level of functionality and no more than X bugs of various levels.
But, as you noted, it is easy to follow the process as the religion instead of recognizing that it is just a means of getting product ready for shipment so it satisfies marketing, the developers and the customers.
In the hypothetical scenario the customer introduces a critical story in the middle of an iteration. This can and does happen in Agile projects. The only problem is that the team may not be able to deliver something that it thought it would because it will be spending effort on the new story. That is ok. The primary goal of Agile is to give the customer the ability to prioritize work and manage the creation of business value.
Also this aversion toward "context switching" isn't particularly Agile. The idea behind TDD, evolutionary design, and small time-boxed tasks is to work in small chunks. I would argue that the ability to "context switch" developers while still developing value incrementally is the whole point of the Agile approach.
I think the point missed by both articles (Joel's and the one he is commenting on) are that specific examples are bad. The real problem is making a habit of emergencies. When you fly by the seat of your pants and constantly have engineers fixing emergencies, then yes, it has a very negative impact on their productivity. Once in a while, however, is to be expected and is okay.
Really what any organization should do is instill the resources and culture for proper QA and operational support for developers. If calling the original engineer is the _last_ resort, because QA didn't catch a bug and operations can't fix the problem, thats fine. All too many organizations, however, have an engineer getting called first for a problem that probably should have been caught by QA, or that should have been caught by the operations people. Engineers hunting down problems and finding a reproducible case constantly is really what kills productivity. If the culture is "don't worry, if its broken the engineer who made it can take time out of their current projects to fix it", then your organization is broken.
Why do I see Joel constantly talking about how disturbing it is to "context switch", when sysadmins like myself are expected to handle a dozen or more tasks, most of them "surprise" stuff, daily? Don't tell me "oh, programming is complex"- so are networks.
So, you get unlimited M&Ms, a 30" screen, aereon chair, and get all upset when you spend an unexpected 2 hours out of your 8 hour workday on an emergency, one a week or so. Meanwhile, I'm working on whatever was left in the IT supply room, have to carry a pager, work 10 hour days because I'm doing 2-3 people's jobs- and I've got a half dozen long term project goals...but I'm getting bugged HOURLY to fix the most trivial shit by programmers who can't be bothered to stick paper in a printer?
If Sarah was a sysadmin and had to waste a day collecting her thoughts after spending two hours fixing a mysql database, she'd be fired. You programmers need to stop behaving like prima donnas.
Please help metamoderate.
When a project goes to production, the team must remain with it for a period of N days to handle the deployment problems. One would expect the majority of issues occur within the first couple of days, maybe weeks. Since it is fresh in their minds, they are the ones best suited to correcting issues. Other projects can be available, but fixing the prior one needs to be priority.
Then, find the developers who are good at maintenance programming. I hate working on long projects with the associated paperwork and spending long hours working with the customer trying to tweak a table. Even Scrum requires some process work outside of development. I prefer maintenance programming that gives me a chance to know many, many systems at a high level and then dig into them when there is a problem. This lets me contact Susie for a 5 minute discussion, and then her get back to her project. There are fewer processes because the fix is often smaller, and it has to be done now. It's amazing how many processes get circumvented when customers can't use an app.
The advantage is you get staff members who may not know the deep details of individual products, but have more information about multiple products and are not tied to specific resource timelines. Plus you get developers with timelines who get fewer interruptions. I agree that context switching is bad, whether you are a sys admin or developer. Finding ways to reduce it, even if the solutions means I spend four hours fixing it instead of two, can have other benefits. For instance, being able to say 'Hmm...we had a similar problem last month on this other application, I wonder if it is a similar problem.' then asking the developer a specific question.
It's a different mindset, and it's not for everyone. People who do it have to be able to juggle multiple priorities and handle context switching well. They also need to be able to 'see the big picture' more clearly and understand how product A works with product B in detail (since many issues often fall there and result in group A blaming group B and nothing getting fixed.)
They also have to contain their ego and find the challenges in maintenance programming that are just as rewarding as new development. I love being 'the hero' by solving production problems quickly when no one else can.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
Joel has a blind spot. Doesn't make him a bad person.
There is no such thing as Agile software. And it is completely ignorant to say "we use Agile". Agile is just an umbrella term for a whole bunch of software development methods. You can say we use Extreme Programming or Scrum or whatever.
In any case, the discussion between Joel and Dmitri has little or no relationship to the relative merits of Agile methods. Dmitri is just some relatively unknown consultant/guru and his individual opinion is just that. In fact, Joel didn't seem to be dissing Agile methods in general, at least not the way I read it. He is dissing Dmitri's doctrinaire approach.
Moreover, the whole discussion is far from illuminating since it is based on a totally hypothetical example. Give me a real world and specific example where we can get a concrete view of what the real priorities and politics of the situation are, and then we can form an opinion on how to behave. Dmitri in his response to Joel talks about
"trust." But if the customer involved is critical to the company, you can be sure as hell that the project manager would (justifiably) get his ass kicked if he ignored the sales request and got all touchy feely about "trust." On the other hand if this is some nundik sales person then it probably can and should be managed by the project manager.
Ultimately, Agile is all about human-centric. As such, you need to understand that organizational politics and behavior can be just as important to the success of a software project as the programming language you choose. Both Joel and Dmitri seem to be ignoring that.
He's not saying "We won't do it." - he's saying "The coder should carry on with their job until a proper decision is made as to whether the context switch is worth it." - he clearly says that the decision as to whether to change what the developer is doing is passed over to the Project Manager to make.
And that sounds right to me. You don't context switch based on getting an email, and you make sure that project managers understand the implications of what they're asking for before you start working on it.
My Journal
There are always more features to be added. The real strength of agile development is that it recognizes this and breaks up the development into small manageable changes, instead of trying to ignore the feature requests.
You're bang on with that assessment. The big issue though is that this type of thinking is near-impossible to sell to anyone, anytime, anywhere.
I believe DHH cried "missing the point," which isn't that inaccurate.
There are a lot of valid complaints about Ruby's speed (although Rails can do pretty intelligent caching); I'm not aware of anyone really attempting to push Rails' scalability to the level that Java can do. I'd disagree with the description of DHH's rants as "FUD," though, by and large. His response to Joel's critique of Rails was that, basically, "I don't think it will scale!" is in a certain sense always FUD -- unless you know of a system out there guaranteed to have no bottlenecks that will show up if its usage increases by an order of magnitude.
Why did DHH pick on Java (I use the past tense because I haven't seen much of this recently)? Because Java people were the first out of the woodwork dismissing Rails. The funny thing is, when you look at some of the biggest, busiest sites on the net -- MySpace, Yahoo, Google, for that matter Slashdot -- while you're not seeing Rails, you're not seeing Java, either. Rails has the excuse of being "immature"; Java doesn't get cut the same level of slack. I'd suggest that the reason has less to do with functionality and "scalability" as it does with simple maintainability. And that's a lot of what attracts people to Rails in the first place. It's not FUD to say that Java is a beast to work with on many levels. It's an opinion and it may not be one you share, but it's not one that's particularly unique to 37Signals developers.
There's a quote that appeared on Daring Fireball today from a golf instruction book: "As for your grip pressure, keep it light. Arnold Palmer likes to grip the club tightly, but you are not Arnold Palmer." In a lot of ways, that's what most of of the Rails "message" boils down to. Rails may not be appropriate for Google, but you are not building Google. (The corollary is that if you are building Google with Rails, even metaphorically, you'll find ways to address those issues.)
You should learn to communicate with people in terms they can understand. There is nothing to be gained fro being right all the time. He asked how long it will take to develop. You gave him some irellevant detail that he doesn't care about.