Sunday, September 25, 2011

Agile vs DDD: A microcosm

I've been carrying on with some refactoring to support simple eso-language interpreters generally, building on the False language work. Next target is Befunge-93, and that led me to a few thoughts as the dog and I meandered along.

Bear with me. False has a simplistic notion of a program counter (PC); in fact, a rather standard one, that we can think of as a uni dimensional object - a number, if you will. Befunge-93 by way of contrast, has a program counter that is a point in a finite cartesian space along with an implied vector of movement.

This is why I pondered agile approaches today. When I commenced this amusing side project to create some eso-language interpreters, I was aware of the Funge style languages, and therefore cannot maintain that I had no  idea that  the classical representation of a PC was going to be flawed.

Thus, any base abstractions I implemented that 'enjoyed' this representation would likewise be limited in scope, and would not advance me towards the goal of a more generalized interpreter framework for the esoteric family of languages. However, I did want to release my False language interpreter sooner rather than later - not because of any latent demand you understand, just for personal pleasure.

My own trivial undertaking therefore, and perhaps unsurprisingly, encapsulates a microcosm of the issues we face in a business sphere during software development:
  • Time to market: I wanted the False interpreter released more than I wanted the generalized framework in place. I was content to trade off releasing sooner against the predicted cost of refactoring
  • YAGNI or TALIA: As I wasn't sure that I would continue, it seemed that YAGNI would apply here, instead of TALIA (previous post
  • DDD: This eso-language idea falls uncomfortably in the middle of a domain driven design/simple exercise. The entire sphere of eso-languages shows great variety, but little real complexity of domain. For example, Funge-98 describes the existence of possible large n dimensional spaces for program execution - but that is more an implementation difficulty detail, as the model implied does not impose a significant cognitive load for most people.
Simplistic notions simply presented.

No comments: