My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
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 - 5 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 - 5 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 - 5 hrs

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)


Subcribe to this comment thread
Remember my details

Picture of me

.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Agile Manifesto & Principles
Principles Of OOD
Ruby on Rails

RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner