I've been asked quite a number of times about the agile principle of Simplicity and the associated XP practice of Simple Design in XP. People ask, "What is simple?" I suppose it's all quite subjective and relative and contextual. This week, however, I endured a rather stark lesson about simplicity myself! I've been at this software development gig for 20 years professionally now, and I'm pretty good at it. I've learned quite a bit about relational and object modeling over the years, and I leveraged my knowledge and experience when designing the persistence mechanism for a system on which I'm working.
Initially, I did the simplest thing that could possibly work, and simply wrote and read serialized Java classes to and from disk. This worked fine, but the Customer for the system needs to be able to track relatively detailed metrics about the system's usage, which was difficult at best with the "simple" solution.
So, I thought, we're going to need to persist this information to a database!! Suddenly, simple serialized Java classes became Hibernate configuration Hell between two independent classes with a many-to-many relationship. I figured that I was just scaling more of the ORM learning cliff when I simply couldn't get the association to work - it was griping about duplicate keys in an association table. After a couple of days of assuming it was my fault, I discovered that there was a bug in Hibernate that created a unique key where it had no business creating one. Removing that key made everything work... at least in my tests.
Ah yes, the differences between tests and the real, integrated application. The bar may have been green, but the application would still barf at times with issues about the Hibernate session having more than one instance... blah... blah... blah... I'll skip the rest of the gory details. In the end, I had spent about 2 calendar weeks working part-time on implementing this solution, and it still wasn't working. I was (and still am) frustrated, and kept saying to myself that it just shouldn't be that difficult.
In the shower yesterday morning, feeling rather defeated, I stepped back (figuratively - it's a small shower stall!) from the situation and asked myself what the Customer really needed. They needed to track activity and run reports. I thought about what activities were to be tracked, and realized that it all fit very nicely into a single table.
I finished up in the shower, and 1.5 hours later had the single-table-based solution working, tests included. It still has serialized Java classes for some data, although those will likely become XML-based quite soon (using XStream, which appears to be very simple!).
So, I had spent about 20 hours trying to implement the "standard" solution, and it never worked properly. I spent 1.5 hours on a much, much simpler solution that does everything that the Customer requires, and it's in production as of 9:30 PM tonight.
In a nutshell, my 20 years of experience using traditional techniques and assumptions came back to bite me on the backside. And that, my friends, is tonight's lesson in Simplicity and Simple Design. I just wish I had learned it a couple of weeks earlier!
Initially, I did the simplest thing that could possibly work, and simply wrote and read serialized Java classes to and from disk. This worked fine, but the Customer for the system needs to be able to track relatively detailed metrics about the system's usage, which was difficult at best with the "simple" solution.
So, I thought, we're going to need to persist this information to a database!! Suddenly, simple serialized Java classes became Hibernate configuration Hell between two independent classes with a many-to-many relationship. I figured that I was just scaling more of the ORM learning cliff when I simply couldn't get the association to work - it was griping about duplicate keys in an association table. After a couple of days of assuming it was my fault, I discovered that there was a bug in Hibernate that created a unique key where it had no business creating one. Removing that key made everything work... at least in my tests.
Ah yes, the differences between tests and the real, integrated application. The bar may have been green, but the application would still barf at times with issues about the Hibernate session having more than one instance... blah... blah... blah... I'll skip the rest of the gory details. In the end, I had spent about 2 calendar weeks working part-time on implementing this solution, and it still wasn't working. I was (and still am) frustrated, and kept saying to myself that it just shouldn't be that difficult.
In the shower yesterday morning, feeling rather defeated, I stepped back (figuratively - it's a small shower stall!) from the situation and asked myself what the Customer really needed. They needed to track activity and run reports. I thought about what activities were to be tracked, and realized that it all fit very nicely into a single table.
I finished up in the shower, and 1.5 hours later had the single-table-based solution working, tests included. It still has serialized Java classes for some data, although those will likely become XML-based quite soon (using XStream, which appears to be very simple!).
So, I had spent about 20 hours trying to implement the "standard" solution, and it never worked properly. I spent 1.5 hours on a much, much simpler solution that does everything that the Customer requires, and it's in production as of 9:30 PM tonight.
In a nutshell, my 20 years of experience using traditional techniques and assumptions came back to bite me on the backside. And that, my friends, is tonight's lesson in Simplicity and Simple Design. I just wish I had learned it a couple of weeks earlier!
Comments