I was telling a friend about my NHibernate Skunk Works project. He asked if I had an application in mind and I said I was planning on doing a wine inventory/tasting notes application and that I would start on the database this weekend. His response stopped me right in my tracks “Why don’t you write a scenario, first”. He’s right, I got so focused on the technology that I stepped right over defining what I expected out of the application. Just because it’s a skunk works project doesn’t mean I shouldn’t be following good developer practices. Here is a very brief description of the intended user (the persona) and an initial implementation scenario.
Persona – Mark Atwood
Mark Atwood recently began collecting wine as a hobby. Mark has a collection of around 100 bottles, and enjoys pairing wines and foods. Mark and his wife Beth often invite friends over to try wines and compare tasting impressions.
Scenario – Wine Inventory and Tasting Notes Database
Mark currently relies on memory for wines that he has enjoyed and what foods paired well with them. As his collection has grown it has become harder to track that information. Mark would like a system that allows him to keep track of his current wine inventory as well as a way to store and retrieve tasting notes. Initially this application will run as a simple Windows Forms application. The implementation should allow for eventual migration to a web-based application to allow the system to be used by multiple users
Mark would like to track the following information regarding a purchase of wine.
- Where/when it was purchased
- Grape variety – Note a particular wine may be a blend of different grapes
The application will allow a user to enter a wine purchase, prompting for the number of bottles purchased and the information stored above. The data will be persisted in a database.
The application will allow a user to indicate that a bottle of wine has been opened. The user will select a wine from the inventory and record the open date. The date will default to the current date.
Mark would also like to track tasting notes for a particular opened bottle of wine. The application will display opened bottles of wine, ordered by most recently opened bottle first. The user will select a bottle and be able to enter the following tasting notes.
- Tasting date
- Tasting notes
NOTE: For this scenario, food pairing information will be maintained in the body of the tasting notes. In the future, the database may be extended to include more detailed food pairing information
I learn by doing. I have plenty of books on software development and I like to read about different technologies, but the only way for me to feel I know a technology is to actually use it to develop software. This doesn’t apply just to languages or technologies, but to methodologies as well. I had read plenty of books and posts on Agile, but it wasn’t until I did my first project using Agile methods that I really “got it”. Understanding the notions of iterations, velocity, and all the other buzzwords is one thing. Putting them in use in a given company culture is another matter entirely.
It is not always possible to put new technologies into practice at our “regular jobs” given the particular problem domain we might be working in. That is why I like to work on what interests me on my time, in my own personal Skunk works. It keeps me up on technologies, gives me something new to work on that I can choose, and can be fun. It also positions me to be ready when the time comes that the technology might be needed on an actual commercial project.
That said, I have been reading a lot lately about NHibernate. I know it’s not exactly bleeding edge, but I haven’t had a chance to use it and thought it might be a good time to put a little of that into practice. Reading an article or a quick start tutorial is all well and good, but it is no substitute for actually doing it. Not to mention a big part of good software is figuring out how to get around the problems that arise, even when you follow all the steps and do everything “right”.
When I talk to people who are doing Agile development, one of the first questions I often ask is “How long are your iterations?”. I ask this not because I am looking for the one magic answer, but to see the variation in iteration length and how people arrived at that decision. Iteration length is very product and team dependent.
Most of the answers I hear are around 4 weeks, with some as long as 3 months. When I say our iterations are 2 weeks I often get a few raised eyebrows.
One of the reasons we went with such a short iteration time is that we have a significant internal R&D “customer” presence. Having a short iteration time allows us to respond quickly to requests for new functionality.
Our internal customers are part of our iteration planning and it is great to hear them talking about iterations. Rarely do I have someone pop in and say “I have to have this now”. More often I hear “Can we get this into the next iteration”. That tells me that our iteration length is working for our internal users and they are not tempted to work around the iterations. That really lets the team focus on the task at hand and not get sidetracked by changing priorities.