For the creative developer-designer, lean is a continuing challenge. uSDLC needed a database. I had already decided to use an embedded SQL system so that I could create an an actor and provide support for migration processes. I chose to use the groovy SQL support directly because it is the thinnest layer between the code and the SQL. I resisted adding DSL functionality like insert, delete, etc methods. Actually I started on that route, realised what I was doing and removed them. It is easier to use a known SQL syntax than add a new complex DSL to learn to do the same thing. The downside is that any server specific SQL is out in the open – where it should be.
I am currently working on a project with a large and messy migration process. All data based applications have a migration problem when new software is released. I have come across it in medical software, accounting programs I have used and in corporate environments. Quite a few years ago I designed a systematic migration strategy. I implemented in once in an object database I wrote (back before the name NoSQL was coined). I convinced myself to implement it into uSDLC as part of the base system. Was this the correct thing to do? No. According to lean thinking I should not have implemented the code until I needed to do the first migration. So as to not lose the concept, uSDLC D3 thinking promotes documenting the design so that the task manager could flag the need for activating and implementation.
Will I learn from this? Of course. Will I do it again? Indubitably – but I will smack myself over the knuckles. Did I delete the offending code in true XP fashion? No, it is still good code, just written at the wrong time.