We've got a big project at $work. Many developers, iterative
development, writing requirements before making changes,
code review before committing changes to the next release, and so
on. All the standard stuff. Not exactly a test-driven or agile
methodology, but not waterfall and certainly not "let's sling some
code and hope it works!"
But it's not the only code we write. There are lots of scripts, support
programs, prototypes, and whatnot. Stuff that we work on that isn't
immediately destined to some future release of the project.
So how does it fit into the process? Well, um, hmmm....
Here's the best analogy I can think of:
It's not a tobacco plant, and it's not a firefly. It's a transgenic
mutant of tobacco + firefly[*].
That is, it's all code, but at the end of the day, there's still
a big pile of "project" code and a big pile of "non-project" code.
The boundaries can be fuzzy at times (we still do requirements,
code review, testing, but don't release to customers), but that
doesn't invalidate the distinction between project vs. non-project
work. So what we have is something of a mutant hybrid -- parts of the
development process work, but other parts don't.
*: Yes, this actually exists. Tobacco plants are easy to
experiment with because they accept new genes somewhat readily, and they
grow fast. Firefly luciferace is a good gene to use to create a
transgenic hybrid because you can see if the experiment
works.
And does your process work?
Ovid on 2004-10-21T16:57:55
As an XP proponent, I'd argue that if your process is not broken, then there's probably no need to fix it. Now if you think you can make it better, that's a different story. I've always been rather astonished at people accusing XP practioners of being dogmatic when real XP tends to be fluid and adapt to the environment rather than the other way around. Any method of managing projects needs to be the same. Assuming your $work gets things done, it sounds like you have that.
Worship the Microsoft Process
scrottie on 2004-10-23T03:10:35
I'm told the leaked Microsoft OS code was for a port of many Windows APIs to Linux and included a hearty dose of Perl to make things build, and er, whatever other psychologically help the code needed to live inside Linux.
I'm not sure what I want you to extrapolate from this, but it could be:
- It so doesn't friggin' matter it ain't funny
- Freak out and use only VisualBasic for the build process to uses your sheer shame from ever allowing you accidentally let any effect of the code impress upon anything
Perhaps Microsoft's contractor doesn't have anything to offer this situation.
How about these:
- Internalize the building process as well as the source code into the application like a compiler bootstrap process. Make the application be its own installer, and when installed, it decompress the sources, builds itself, then causes the newly built copy to build yet another copy and compares the two binaries for any difference. Do not do this recursively.
- Rewrite all of the helper scripts, no matter what they do - even munge binary data - in gmake - to assure they're never run correctly anywhere but the development environment, and use this logic to exempt them from any methodologies.
- If you're feeling strict and proper, use strong type checking. Why sweat the little things when you can sweat the big things and really annoy yourself?
- Take your mind off the whole deal and put it all in perspective by hiring some junior programmers with full intent to never use any code they write and watch them try to build objects in the system. This might even have a positive bonus effect of demonstrating where interfaces aren't clear and the fragility of the program by how it deals with invalid data, inconsistent state, and other abuse.
- Rewrite it completely aspect oriented, throw that away, rewrite it completely functional, keep that but bolt objects back on, and then rewrite it in assembler. You'll be so good at writing the whole thing your ability to pound out interface after interface will dwarf the benefits of any development process.
- My personal favorite: complete a prototype before even discussing when the program might be completed, but under no circumstances tell anyone you've made a prototype. Okay, I've just broken my own rule.
-scott
