I was reading a post this morning about the utilization of state machines in code and how most developers don’t use them. The main comment that I noticed was the title above “We Don’t Need One Until We Do”.
I have definitely found this to be true however that comment has several implications that are worth noting that go well beyond state machines and is a commentary on development in general.
1. Requirements – In the ideal world we would have perfect requirements that would have foresight at least 5 years into the future, but the reality is that it isn’t normally that “we need one”, it is the business that needs it. However the business doesn’t really know what technology they need to do anything and will never fully understand the implications of those decisions. As such it can be invaluable to have a technology person the understands the basics of the business to at least be able to point out where something maybe much bigger than the requirements indicate.
2. We just don’t know – Similar to requirements regardless of the foresight and the business, you never really know what is going to happen, the economy takes a downturn, you suddenly have legal changes which impact your application, your company signs a big client which is different than anything in the past. These all come together in ways that you can’t possibly foresee even a couple of years in advance, let alone a decade (gasp). I only point this out since even making the perfect decision at the point in time it is made, there will still be things you would have done differently if you had to do it again.
3. Currency (Technological Debt) – Finally, both of the above points above lead to a day of reckoning where the customized component you have created with become so large and unwieldy that it is impacting everything around. Once you reach this point it is already too late. Development takes longer, testing takes longer, deployment takes longer, everything is taking so much effort that you have to replace it, however it is also so late that the endeavor to replace it will not be a trivial task. Meaning, lots of time and lots of money invested in something with a fairly intangible business value. As often as not, people are comfortable with “the ways things are” and although might see a need to change, don’t think it is that bad.
Unfortunately the 3 items above tends to lead to “go big or stay home” syndrome. Every little item gets wrapped up in a giant process and architectural exercise requiring review and signoffs and everything else under the sun. Ultimately driving costs through the roof. The real key for us all is to be able to understand the business needs enough to know whether or not you need to go for the gusto and buy that big enterprise component, or whether it is a small enough side line item that rolling your own is perfectly fine.
At my company we have a few poster children for these things like this as I am sure we all do, but the best example of one is a document generation engine we built 10 years ago. Effectively it started as a “find and replace” string parser, however 10 years later it is a very complex custom piece of software that takes months if not years for new people to fully understand what is going on in there. This would all be fine if our primary business was “document generation”, but in reality it is a service that simply supports the application.
In the beginning would I have done things differently? In the beginning, maybe a little, but probably not much, the component served its purpose quite well for 5 years. However, after that we started to add features to the document generation that culminated into the current issues, which is basically a very complex custom piece of code, which is buggy at best. There are lots of reasons for that (some in our control, some not) that are worthy of a different post, but suffice to say that currency has finally caught up and things need to change.
In the end the key for all of us, is the understand when we need to go for the gusto and when we don’t. And then when we didn’t go for the gusto the point at which we need to bite the bullet and move to the better model, rather than just bolting on more of the same.