ThoughtShapes - Team - Comments

Hi Robert! What you say

Jay — Fri, 02 Nov 2007 20:24:09 -0400

Hi Robert!

What you say makes a lot of sense, no surprise there, but I'm currently working on a project where the decision to use a particular database technology was made early on... pretty much at the beginning. Why? Well I don't want to use the wimpy excuse that "I wasn't working on the project at the time this decision was made", and even if I was I might not have been in position to directly work around this decision. Some of the decisions to select a database early were based on the following:

Our product is a website that we want to achieve scale on. And we wanted to be able to make performance measurements ASAP.
A database brings decades of doing certain things well. And we wanted to leverage that

Having said that, I also should tell you that: A) We are using Agile just as you describe and B) I >think< we used something akin to the repository concept in order to isolate the DB from other production code so that the other groups (we have multiple scrum teams running) wouldn't be blocked. I say Akin because we don't have a true in memory repository. We use NMock to "stub" out interfaces and inject test data.
With both of these statements, we are in a position (should we need to go in this direction) where we could change the DB, remove the DB etc, in a "safe": we have unit tests to catch dependencies but is anything truly 100% safe ;), and speedy (in a sprint) manner.

Having said all that, I do struggle (as I mentioned to Rjae) with the fact that we have what some people would consider business logic written into stored procedures, and I worry what the implications of changing the DB technologies would be underneath the interfaces we have.

So I have no problem with you saying "start with an in memory repository first." I truly feel that Agile and your 4th point "I’d make remaining neutral with respect to the piece of technology a design requirement and ensure that the development team knew to isolate that decision behind the appropriate interfaces" above are the ones that help us rule the day.

Great post! There is a TON of good material here. I'll come back to this post frequently.

The stuff we put up here is

Rjae Easton — Fri, 19 Oct 2007 12:46:36 -0400

The stuff we put up here is not so useful unless it is applied. It is a pleasure to hear that you find the thoughts compelling; your ideas around screening collaborators could yield what you are looking for - as long as you build something with them (however that materializes).

Feel free to tag this post; come back and let us know how your project progresses.

Thank you for this

Anonymous — Fri, 19 Oct 2007 08:13:06 -0400

Thank you for this interesting post. I have been wondering about how to "screen" potential collaborators for a complex open-source project I am working on and as a result of your well reasoned article now realise that the best approach is to let the end-users of my prototype create variants (or extend the code-base with new "types" to do the things that they are interested in; but I will probably never have time to address), and on the basis of the quality of their code and my subsequent communications with them I should be able to pick out those few developers that I want to have direct contact with as a pseudo-project leader.

Obviously, this will be all very informal and I am assuming that my initial prototype attracts sufficient users for the subset of them that are inclined to program will form a community of sorts.