Friday, June 27, 2008

R&D Coding and Changing Requirements

I work on a lot of R&D type projects. Basically I'm building proof of concept applications or applications that support a larger goal. These applications, for the most part are throw-aways or will not be used beyond the life of the project and also will probably not be used by real users. And, as you can expect, requirements for these types of projects change a lot and new requirements are constantly discovered as you go.

The handling of changing requirements is really not too much of an issue and it's usually easy enough to handle those. Short development cycles and refactoring help to minimize the impact of changing requirements. But how much refactoring do you do when the project is just a demo? Should you really spend the time and effort to re-architect some new requirement that has popped up that throws a wrench into your design? Or do you just do a quick hack and patch up your code to handle this new "feature"?

What do you think? Where do you draw the line between maintaining great code and getting the job done when working on a demo/throw-away application?

2 comments:

aaron said...

first of all, congratulations if you are really working on Research & Development. Most of the time its just "vaporware".

i've recently had a conversation with one of my engineers about how to approach software development in R&D. and what i concluded to is that we should shoot for "high budget" applications. and what i meant by that is some aspect of the software better be awesome. and i think if we achieve that then that should keep us pretty excited. maybe it takes an awesome UI. or an awesome algorithm. or awesome quality. i'm fine for shooting for one of those. often times R&D projects just get flattened out into an application that does 1000 low budget things.

so getting back to your question. i have no problem throwing away code. nor does a quick hack bother me as much as not having anything that's high budget.

so if the UI is just okay, the research is just okay, and the quality is just okay, and the design is junk then... that equals boredom.

aaron said...

yes, so after chatting with you about this more. i would leave it in as a hack for now. especially if you don't think that "feature" has a use case for any significant time.