Linked by Eugenia Loli on Sun 2nd Oct 2005 20:30 UTC
General Development The Scrum methodology can pose a challenge for software testers who are used to more traditional waterfall-inspired development processes. Jonathan Kohl relates his experiences working on Scrum teams who found some clear advantages in changing their methods.
Order by: Score:
Excellent article
by rayiner on Sun 2nd Oct 2005 21:12 UTC
rayiner
Member since:
2005-07-06

I'm glad to see more emphasis being placed these days on iterative processes in programming. It marks the evolution of programming towards becoming a mature engineering field. I'm somewhat puzzled that in all the talk of good processes, there is no talk of good tools, but I figure that the importance of good tools will become evident to programmers when they sort out the problems related to methedology.

Reply Score: 2

rcsteiner Member since:
2005-07-12

There ain't anything new under the sun -- just different packaging. :-)

Also, a good tool can help, but in many cases a tool is not an adequate good substitute for a clueful developer (no matter what project management weenies might tell you <vbg>).

Reply Score: 1

It seems to me
by Anonymous on Sun 2nd Oct 2005 21:59 UTC
Anonymous
Member since:
---

That it may be too stressing for some developers to work this way.

Reply Score: 0

RE: It seems to me
by rayiner on Sun 2nd Oct 2005 22:04 UTC in reply to "It seems to me"
rayiner Member since:
2005-07-06

Why? Because they actually have to work at a regular pace, instead of trying to get everything done in the last week?

Reply Score: 1

Marketing of development team practices
by Anonymous on Mon 3rd Oct 2005 00:44 UTC
Anonymous
Member since:
---

I'm not a big fan of "XP this" and "Agile that", with authors promoting fluffy and expensive books, usually from Addison Wesley.

It's not that the individual techniques are bad. The ideas of short iterative development cycles, writing comprehensive unit tests early in the game, and holding design and code reviews are time-tested; they go back decades, though they aren't universally adhered to. But the authors and trainers of these methodologies, probably realizing that packaging best practices isn't enough to justify the funny names, come up with dogmatic approaches - the team must meet for 15 minutes every day (even though some developers are early risers, others late risers, and others do lots of work at home), all unit tests must be written before any code, programming must be done in pairs, etc.

An intelligent person reading one of these books (hopefully borrowed from someone else, because they aren't worth the $34.95 cover price) would consider it as another bag of tools which can be mixed and matched on a per-project basis. I don't think any of these prepackaged methods would be a good approach for developing an operating system kernel, for instance, even if all the developers were on the same campus.

Paul G

Reply Score: 1

Unit tests written before code
by Anonymous on Mon 3rd Oct 2005 01:56 UTC
Anonymous
Member since:
---

I've never been able to do this well. It feels more natural to develop the first iteration of my unit of code, then create the unit test. The unit test will invariably drive the remaining development iterations of the module that I'm building. The unit test will evolve with each iteration as well.

Am I missing something? Maybe I just stuck in my ways.

Reply Score: 0

RE: Unit tests written before code
by rayiner on Mon 3rd Oct 2005 03:17 UTC in reply to "Unit tests written before code"
rayiner Member since:
2005-07-06

I can't generally do this either, and I'm not a particular big fan of the practice. Designing the interface before at least prototyping the code always seems to lead me to baroque, inelegant interfaces. I prefer to start with a basic kernel that does the essential job of what a particular component needs to do, then use the knowledge gained from that exercise to design an interface that fits both the client of the component, as well as the implementation of that component.

Reply Score: 1

Scrum Concepts
by Anonymous on Mon 3rd Oct 2005 02:04 UTC
Anonymous
Member since:
---

I like this idea and have used it in the past with some success, but our time frames were a little different. A meeting every few days worked well for us, and our sprints were usually between 4-8 weeks (never exceeding 8). The result of each iteration was a internal release for QA with fully implemented functionality.

Reply Score: 0

RE: Unit tests written before code
by Anonymous on Mon 3rd Oct 2005 03:58 UTC
Anonymous
Member since:
---

Good. I thought it was just me.

Reply Score: 0

The Mythical Man Month got it right
by JustThinkIt on Mon 3rd Oct 2005 13:04 UTC
JustThinkIt
Member since:
2005-09-04

The software beast is not easily managed.

I've never heard of any software developer delaying code writing "until the end". Nor would that make good software.

Props to PaulG's comment, and to the 'anon' who talked about writing the first crack at the code before the first tests -- I do this also.

When I worked at Hughes Aircraft on the Military Automated Air Traffic System (MAATS), bugs had a lifetime of months, possibly years -- the exact opposite of my approach which is to interact with other programmers as needed and fix bugs ASAP.

The infamous waterfall technique is an IBMism, pound for pound the worst software writing company in the world.

Microsoft comes out with tons of builds and "eats their own dog food" -- I am quite sure this leads to programmers 'talking to' programmers a fair bit.

Bottom line: I think most of good programming is common sense, and that most managers get completely in the way. Proven by the fact that the best programs were one man bands, like Borland's early stuff, Hertzfeld's contributions and of course The Woz. Even Gates did his best work early, and on his own -- once famously coding some core software functionality on the way to delivery to the client.

Reply Score: 1