+972 52-548-6969
Hibernating Rhinos PracticesDesign
One of the things that I routinely get asked is how we design things. And the answer is that we usually do not. Most things does not require complex design. The requirements we set pretty much dictate how things are going to work. Sometimes, users make suggestions that turn into a light bulb moment, and things shift very rapidly.
But sometimes, usually with the big things, we actually do need to do some design upfront. This is usually true in complex / user facing part of our projects. The Map/Reduce system, for example, was mostly re-written in RavenDB 2.0, and that only happened after multiple design sessions internally, a full stand alone spike implementation and a lot of coffee, curses and sweat.
In many cases, when we can, we will post a suggested design on the mailing list and ask for feedback. Here is an example of such a scenario:
- Proposed change to TransformResults – May 18, 2012
- The New Transform Results – Jan 25, 2013
In this case, we didn’t get to this feature in time for the 2.0 release, but we kept thinking and refining the approach for that.
The interesting things that in those cases, we usually “design” things by doing the high level user visible API and then just let it percolate. There are a lot of additional things that we would need to change to make this work (backward compatibility being a major one), so there is a lot of additional work to be done, but that can be done during the work. Right now we can let it sit, get users’ feedback on the proposed design and get the current minor release out of the door.
More posts in "Hibernating Rhinos Practices" series:
- (22 Feb 2013) A Sample Project
- (06 Feb 2013) Design
- (05 Feb 2013) Pairing, testing and decision making
- (04 Feb 2013) We are hiring again
- (31 Jan 2013) Development Workflow
- (30 Jan 2013) Intro
Comments
How do you document your designs?
Sean, Blog posts :-), emails, those sort of things. We rarely do formal design documents.
Do have a post planned on how you introduce new employees to the codebase?
Kristof, Not really no.
I through that you were going to say "I force them to read this blog" ;)
Maybe somewhat off topic, but the new TrarnsformResults looks great! I never would have known about because I find it really hard to keep up with the google group and often miss stuff like that. IMO, It would be helpful if you posted threads that discuss upcoming changes, features, suggestions to the blog or ravendb.net - I would love to be able to see and sometimes respond to these exciting new features.
Ayende - I like it!
Two quotes that have stuck with me for years are Fowler (in UML Distilled) saying "do enough design" (but no more), and "use the source, Luke" from my Delphi days - they used to ship the VCL source so you could learn from reading it. Wonderful!
When doing specs for user interface features I find that modelling the interaction between the UI and the high level API is the best way to start. This way, if you need to discuss changes on either side, you can easily think about how it effects the other.
Also, impressive use of the word percolate :)
Chanan, What you see there is a design only. It isn't implemented yet. Once we have that implemented, you can be sure I'll be blogging about it and that we will have the docs for it.
Dan, Why impressive percolate ?
Yes I know. I think it would be useful to have a page somewhere that has a link to all those idea threads so that they can be commented on prior to implementation, just like in that thread you posted from Transform Results.
Chanan, That is why we have the mailing list for. We post several such items a week, this is a big one sure, but we seek feedback on a lot of issues. It isn't practical to post to too many places.
Comment preview