A month ago, I blogged about the frustrating procrastination cycle I seemed to have got myself into. While I’ve come a little way since then, I’m still not 100% happy with my progress. That being said, I guess I’m a bit of an old-school thinker: I still measure progress in lines of code (which has been precious few so far).
Progress for December 2010:
- Established an identity for the product (i.e. a logo)
Received a contribution from a brilliant designer on crowdspring.com. Am absolutely smitten with the result and I can’t wait to share it!
- Established a Development environment on my home network/iMac.
VMFusion3.1, VS2010, MS-SQL2008 R2, SSMS, RedGate Compare, ApexSQL APIs et al
- Decided on the technology/tool stack to target.
VS200x and MS-SQL200x. Very subject to change, though.
- Re-evaluated the whole approach for the tool.
My original design involved creating an “append-only” database migration scheme, where the tool would script all the additive changes automatically, and the user would be responsible for manually scripting the destructive ones. After getting a bit further into the nitty-gritty (an article on SimpleTalk really helped evolve my thinking: “When database source control goes bad“) I realised this was going to result in unmanageable complexity, so that idea has been tossed. The new design involves a fusion of a typical database compare method that owners of VS2010 premium and RedGate/ApexSQL Compare would be familiar with, combined with a more linear database migration technique.
- Yet more research!
Have been exploring different ways of looking at/extracting/rolling-out/rolling-back database changes. I’ve become fascinated by the way that SQL Server transaction logs work; I really think there’s some great opportunities to be exploited in a developer’s sandboxed world! ApexSQL have an excellent log-reading API that has been fun to play around with.
Additionally, I believe I may have found my whole reason for doing this, inspired by a blog post by Tim O’Reilly which advocates “working on stuff that matters”.
My end goal is to introduce the idea of play into database development. To enable the same kind of process that allows developers to quickly experiment with new code logic to squeeze that extra bit of performance out of a code library or to iteratively create a UX that delights its end-users. It’s incredible that we have all these wonderful tools for engineering front-ends/middle-layers etc but why not the back-end? It seems incredible to me, given that (in my experience) databases are usually the longest-living artefact of a system.
Also, I want to allow my customers to break-down change barriers within their organisations: databases are often treaded around very carefully and are rarely refactored in any meaningful way after the version 1.0. I think this needs to change!