Unusual Subroutines

The blog and musings of Christopher Allen-Poole

When do you look for tomorrow?

For the last two days, I've been in a codeathon at work. Our team has been working on creating a new project which helps fans get better insight into Fantasy Sports data. It's not terribly impressive (yet), has raised an extremely important function: when do you start thinking about tomorrow?

There are features in this project which we're not going to be able to flush out. For example, we should be able to handle all of the following:

  • Real fantasy-provided data, but we're using only an extremely small sub-set.
  • Direct interaction with input hardware instead of calling through API
  • Genuine predictive modeling, instead of ninth-grade math approximation
  • Support for alternate statistics
  • N-level charting
  • Team defenses should be considered players in our input model
  • unit testing
  • … and I could go on

For most of these, we're opting to go with the more immediate, easier solution than what would be the long-term architectural approach. The mentality is "get it ready for the demo" not "build something that will last." It's hard to tell the wisdom of that, but it does bring to mind something that Joel Spolsky talked about1, namely the dissonance between presentation and actual ability.

So the basic problem is this: when developers put out a demo, they are showing something to non-technical people. It doesn't matter how technical the person is, they're still not going to be able to appreciate it if they're out of the context. I understand Java well, but if you were to throw a Java presentation my way and say, "well, you can't see anything yet, but the unit tests are all passing," that wouldn't give me any sort of idea as to what was actually being built, what the team's intensions are, or even whether this project is worth my time. Maybe it works, or maybe it is just a waste of time. I don't know either way.

On the other hand, if you create something that a human can see and interact with, it becomes more real. Instead of having to imagine how something will work (or whether it will work), they have an example of something like the finished project working, albeit in a limited way.

In all of the above examples, the slower way will take fewer man hours overall. That is the cheaper approach, by far, but choosing the better architecture at the beginning would lead to a longer period before we are able to demo. Without being able to demo, we lose our ability to get investment and feedback. We remove ourselves from any form of iterative development. While this is not necessarily the worst scenario in the world, in many cases, client/manager/executive sponsor feedback is imperative to make sure that the project doesn't go off course. This means that while the longer approach may be better in some ways, it dramatically increases the level of risk.

Unfortunately, there are no clear guides here for which of the above should be prioritized after the demo. Some of the bullets are riskier than others. Some of them actually decrease the overall risk profile of the project (looking at unit testing for that one). Some will rapidly add functionality at low cost. But all of those should wait until after the demo, because if they don't, then our chance to demonstrate value drops to zero.

There is a bit of a personal lesson in all of this, too. I've long held that doing things the right way, the first time, was better for everyone. I still believe that (for the most part), but looking at this problem in the light of this codeathon, it seems that level of risk needs to be considered as part of the costs of an approach. While the "right way" may be better in some circumstances, the "quick way" is often the budgetary need.

There's also the fact that things which are low-risk and easy happen the fastest. If I'm moving from a mediocre approach to one function to a slightly better one, then it probably won't cost too much to merge and deploy that. On the other hand, if I take a longer period to implement the better approach in the first go, I significantly increase the likelihood of a merge conflict. One merge conflict handled badly will cost more than you can save with the best architecture in the world.

  1. OK, so I don't have an actual reference for this, but I'll swear on a stack of a thousand… stacks? that Joel brought this up first. And, Mr. Spolsky, if you are reading this in some mythical future, remember, falsely attributing good ideas is to someone is far more sincere flattery than imitation. 

blog comments powered by Disqus