@ 07:57AM | 2005-08-25
Thanks a lot for your real life account on Agile development. I have yet to use it in my own development process, so I'm always curious to hear how it is working out.
According to Kent Beck in "Extreme Programming Explained", the classical software project models like the waterfall model came from engineering like construction work and don't fit well the software creation process, because software is easier to throw away than a half-built house.
It seems there must be some middle way as you point out. Joel Spolsky points out that he is a believer in "Big Design Up Front"
Do you think you would have had less re-writes with a development cycle of two to three weeks instead of a month? Maybe it is also easier to apply Agile technologies in a purely OOP world where the likelyhood is higher that some classes remain useful no matter how much else you have to throw away.
@ 08:12AM | 2005-08-25
Ooops, sorry for the duplicate entries. Please keep the last one.
@ 09:41AM | 2005-08-25
I thought this Dilbert cartoon was pretty apt
@ 10:43AM | 2005-08-25
I don't have an issue with throwing code away -- I do it all the time, and as Gerald points out, if your cycles are close enough together, you don't go too far down one particular road -- HOWEVER, I do have an issue with end-points. Specifically, not defining them.
With agile approaches, I don't see how you ever really finish something and move on to the next project!
@ 12:31PM | 2005-08-25
I have been reading more and more on Unified Modeling Language and trying to apply it to my projects, and I really like the simplicity of those parts that involve the user. Stick figures seem to be easy for people to relate to, and it is as much detail as I want in the hands of the user.
Worse than the typical user is the executive user who likes to base his/her ideas of software architecture on the last article written in PC Weekly.
Bottom line, agile development is simply allowing the glacier that is the project scope, to become a fire hose in the hands of those who should not have it.
@ 04:55PM | 2005-08-25
My senitiments, pretty much exactly (the original post, that is). The push for regular "deliverables" in an iterative cycle kills the concept of sound architecture. If an app is non-trivial, then there SHOULD be a big chunk of time during which absolutely nothing is happening from an end-user perspective. Ideally, nothing should be happening from a code-submission perspective either. I'm not even sure I'd like to see anything committed to anything as formal as a Visio drawing, 'cuz as soon as you formalize it to that level, you begin to build to it, to commit to it. A "good enough" architecture never is.
@ 09:59PM | 2005-08-26
Finishing a project is always hard. And in the Notes world, there is the saying that if the application is no longer modified, it is probably no longer in use.
As mentioned before, my knowledge on the topic is purely theoretical. As such, I have found the book "Planning Extreme Programming" by Kent Beck and Martin Fowler very helpful. Especially the chapters about "The four variables" (which are cost, quality, time and scope) and "Scoping a project" were nice. I believe you can finish such a project either by limiting the features or the time used. If the feature list changes with more important items, then only with items that take about the same time to implement. It's a little bit like on the market - haggling and bartering...
Kent Beck also stresses the importance of release planning. Therefore, your 1.0 release must be a release where the minimum number of the most important business items were implemented.
@ 02:10AM | 2005-08-27
Great comments guys. Thanks! I especially like the Joel Spolsky article (Dilbert cartoon being a close second
Glad I'm not the only one struggling with this. I haven't given up on XP-type programming completely, just some of this "just jump in and start coding" stuff. I don't mind rewriting code -- Lord knows I do it often enough -- but I do mind having to do it because I was just sloppy in the beginning. It's just a tough balance between proper planning and keeping the users happy, that's all.
@ 06:32AM | 2005-08-27
I'm on the other side of this argument. I have been doing agile development for the last couple of years, and in general it has been a pleasant experience both for me and the customers.
There is one caveat: You will need to work in a technological environment that actually supports agile development. And Lotus Notes just isn't.
I'm expanding on this on my blog
@ 06:59AM | 2005-08-27
Not agile development is the problem, doing so in Lotus Notes is.
I have expanded on this on my blog:
Lotus Notes is not agile
@ 02:01PM | 2005-08-27
Good points made in your blog entry. You other guys/girls should take a look. I'll update the original entry with a link when I get a few minutes.
@ 07:03PM | 2005-08-29
Gerald's mention of "The four variables (which are cost, quality, time and scope)" reminds me of something my mentor/supervisor told me when I first started out in consulting. I've found it to be true, even now that I work in house.
Clients must be made to understand the "two out of three" theory. They can get quick and good but pay for it, quick and cheap but sacrifice quality, or good and inexpensive but miss their deadline by a long shot. They can't have all three - high-quality, within their budget, and by their deadline.
add a comment
HTML markup is
allowed in your comments, although URLs will be automatically converted to links (make sure there is a space before and after the URL).