In this week's advice from
MJWTI,
"The Way That You Do It," Chad Fowler talks about process and methodology in software development. One quote
I liked a lot was:
It's much easier to find someone who can make software work than it is to find someone who can make the
making of software work.
Therefore, it would behoove us to learn a bit about the process of software development.
I never used to have any sort of process. We might do a little requirements gathering, then code everything
up, and show it to the customer a couple of months later. They'd complain about some things and offer
more suggestions, then whoever talked to them would try to translate that to me, probably a couple of
weeks after they first heard it. I'd implement my understanding of the new requirements or fixes, then
we'd show it to the customer and repeat.
It was roughly iterative and incremental, but highly dysfunctional.
I can't recall if it was before or after reading this advice, but it was around the time nevertheless that I
started reading and asking questions on several of the
agile
development mailing
lists.
Doing that has given me a much better understanding of how to deliver higher quality, working software on a timely
basis. We took a little bit from various methodologies and now have a better idea of when software will
be done, and we interface with the customer quite a bit more - and that communication is richer than ever
now that I involve myself with them (most of the time, anyway). We're rolling out more things as time goes
along and as I learn them.
I'd suggest doing the same, or even picking up the canonical books on different methodologies and reading
through several of them. I haven't done the latter quite yet, but it's definitely on my list of things to do.
In particular, I want to expose myself to some non-Agile methods, since most of my knowledge comes from
the Agile camp.
Without exposing yourself to these ideas, it would be hard to learn something useful from them.
And you don't have to succumb to the dogma - Chad mentions (and I agree) that it would be sufficient to
take a pragmatic approach - that "the best process to follow is the one that makes your team the most
productive and results in the best products." But it is unlikely you will have a "revelationary epiphany"
about how to mix and match the pieces that fit your team. You've got to try them out, "and continuously refine
them based on real experience."
I don't think it would be a bad idea to hire a coach either (if you can afford one - or maybe you
have a friend you can go to for help?), so you've got someone to tell you if you're doing
it the wrong way. If you have a successful experiment, you probably did it the right way. But you won't
likely know if you could get more out of it. The same is said of doing it the wrong way - you may be
discarding an idea that could work wonders for you, if only you'd done it how it was meant to be.
In the end, I like a bit of advice both
Venkat and
Ron Jeffries
have given: You need to learn it by doing it how it was meant to be done. It's hard to pick and choose different practices without
having tried them. To quote Ron,
My advice is to do it by the book, get good at the practices, then do as you will. Many people want to skip to step three. How do they know?
Do you have any methodological horror stories or success stories? I'd love to hear them!
Update: Did I really spell "dysfunctional" as "disfunctional" ? Yup. So I fixed that and another spelling change.
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Leave a comment
I'd love to hear a little more about the details of the approach you find yourself using now . . . I've found both processes and supportive tooling to be key to developing solutions efficiently and I'd love to hear more about some of the tweaks, tools and approaches that have worked for you . . .
Posted by
Peter Bell
on Nov 24, 2007 at 02:43 AM UTC - 6 hrs
Hey Peter,
There probably won't be much new to you, because it's all stuff we've talked about randomly at different times. However, I think it would be great to codify it into a post, let it be critiqued so that I can see where improvement can be made. Excellent idea you've given me there!
Anyway, I'll shoot for Monday - I've got a helluva weekend ahead of me because I wasted too much time over Thanksgiving week. My beloved Houston Dynamo won the MLS cup for a 2nd straight season, so I spent a lot of time celebrating instead of getting my school work done. =)
Posted by
Sammy Larbi
on Nov 24, 2007 at 06:13 AM UTC - 6 hrs
Yes, I think you have point right there but using different approaches and specific tools can also be useful in business and development solutions.
Posted by
Mary Dorreen
on Nov 16, 2014 at 07:46 AM UTC - 6 hrs
