Interestingly the SPECIFICATION for the application he is writing is quite loose and ill defined. It started with a set of pencil sketches of an outline of the general functionality. These sketches were then turned, in true TDD style, into a series of tests that failed, around which the code was then written.

So, the specifications became tests, which spawned the code.

Why bother with the code? Why not make the specifications BE the tests and these BE the code?

We would then simply (OK it REALLY isn’t simple) write the Specifications which would have attached to them all theTests that make the specifications firm in detail.

This seems to be a little radical as, of course we have to write code to make the tests pass, don’t we? Well, I’m not at all sure we do.

The argument may be that if we only write the tests than we are not actually exercising code, but then again in TDD there is no code without tests and the only arbiter of the correctness of the code IS the tests. TDD protagonists can be quite brutal about this deeming the tests passing as being the only requirement of the code. HOW the code works and any functionality or side effects that are not caught by the tests are irrelevant.

TDD does not prescribe the architecture that is to be used to build the system for which the specifications and tests are written. Clearly, in every system some sort of architecture is either prescribed or emerges from the development itself. However, it is perfectly possible to pre-define the architecture that is to be used and to use stereotypical mechanisms for translating the specifications and tests into some form of code.

Related Tags:

There has been a great deal promised by this paradigm, among them, greater productivity, greater re-use, easier understanding of the code produced etc. However, I have seen no evidence for any of these in the paradigm per se. There has certainly been strides made in the use of modern languages such as Ruby and Python which really do seem to allow talented programmers to produce good clean code in relatively short timeframes. Others, JAVA and C# for example seem to revel in the mass of complexity they engender.

Most of our experience has been in the Microsoft .Net environment, particularly the use of the object oriented language C#. While the stability of the architecture is extremely good, we have experienced similar issues in the mass of complexity that is required to implement ANYTHING.

Related Tags:

Although I can see that there are many benefits arising from this approach I am still totally dissatisfied with the development mechanism in general. There still seems to far too much to do to achieve simple results and proportionately greater work in doing anything moderately difficult and almost impossible to achieve anything large without massive pain.

I shall have to define a scope for this assertion as any remedy can only be envisaged within the domain with which I am familiar and that is Administration software for Financial Services. This discussion MAY be applicable outside of this domain, but I cannot validate that.

So, what is my problem?

Well, despite the intervention of some thirty-five years since I started out in this domain there APPEAR to have been no improvements in the ability of the business to express its requirements for automation. Bizarrely, we have more complexity, more obfuscation, more reliance on highly specialized technical resources and less ability to go from business problem to automated business solution, than ever before.

I’m not sure that I would have noticed this is had remained firmly in the specialist developer “camp” where my role would have been to implement business automation on behalf of another business. In this role one has no real motivation to simplify the mechanism of getting from problem to solution as the fees one earns are directly related to the complexity and therefore the time it takes to execute the implementation.

However, I have chosen to a step to the dark side and actually become an executive member of a management team that runs a financial services business that actually HAS the problems and NEEDS the solutions.

And it has never been so hard to achieve.

The root problem? There is no viable mechanism for the business to express its requirements in a way that leads to a solution in a concise, unambiguous and efficient manner.

What is the solution? That’s what I’m attempting to explore.

Related Tags:

Related Tags: