Design Decisions

I was practising a Kata I haven't done in a while because I wanted to add a recording to the new Page I created dedicated to TDD Katas. The Kata in question was the Roman Numerals Kata (From Roman to Arabic).

After doing the Kata I ended up with this implementation:



This is fine, the solution worked but I just didn't like that those two nested loops seemed a bit of a lot of complexity. Probably not the best solution from the point of view of performance. I wanted to try something else. So I deleted that code and without deleting the tests I wrote this:



To me this seemed a bit better and probably faster. Optimisations are something that we should always postpone. Remember the saying?

Make it run, then make it nice, then make it fast.

Early optimisations can lead to unwanted over-engineering and some other problems. TDD teaches us that we need to grow our code gradually. But then how can we just refactor to something completely different than what we just got?

Once we have written all our tests and we are happy with our refactoring, the tests will act as our documentation, so even if we were to delete all the code and just leave the tests, we could recreate the code. So that is what I did initially to create that second implementation.

After observing the new implementation and compare it to the previous one, I decided to TDD to see if I could get to the code in the second implementation. I discovered that at the point where I was doing the refactoring after making the test for number 6 pass, here was the place where I could make a design decision and choose not to extract an enum and instead try something else.

This time the Kata has once more proven that TDD is not just capable of making safer code but also drive the design even when we are looking for a faster solution than the one we have.


Here the video for that Kata:
 

Dealing with Hardwired dependencies part 2 - Making a design decission

In this second video, I make a design decision and I remove the temporary refactor that I did earlier.
The Seam was not a bad idea, but it was a temporary solution only until I make a decision about the design of the class.

Contextual Vs Composable design

Today at work, a colleague told me about a very interesting topic I never before thought about; Composable Vs Contextual software. I decided to read a bit more on the topic and just post some brief conclusions.

When designing new software, probably one of the most important questions we want to ask ourselves are:
-Who is going to use it?
-How is going to use it?

By talking to the future users of the solution, we can gather relevant information that will help us give answers to the above questions and therefore, determine if what we have to build has to be composable or contextual.

So what is composable and what is contextual then?
If you type in google "define:composable design" or "define:contextual design" you will get really good definitions(Just in case is not clear what I am about to say next). But I will also try to give a more reductionist definition with my own words:

-Composable: For me a composable system, is boundaryless in what regards the interactions the user can have with its components.

-Contextual: For me a contextual system is a system that defines constraints, flows, etc... to guide the user in a predefined way, when it comes to the interactions with its components.

Pros and Cons
So as I said before the important thing is, to understand who the user is and how is going to use the system, but is also good to be aware of some advantages and disadvantages of both designs:

Composable
Pro: Big flexibility.
Con: With great power comes great responsibility(It can be dangerous if in wrong hands).

Pro: Less maintainability
Con: May require training/mentorship for less experienced users

Pro: Generic/Multipurpose
Con: Non-Specific, could be used for the wrong purpose.

Pro: Fast for experienced users
Con: Slow for less experienced users

Contextual
Pro: Solves a problem
Con: Is limited to just that problem/Not reusable in other problems

Pro: Its easy to use
Con: Needs maintenance

Pro: Fast for less experienced users
Con: A constraint for experienced users

Pro: Does most of what you want fast and easy.
Con: Dietzler’s Law for Access(Does 80% of what the user wants easily, but does another 10% with difficulties and finally is unable to do the other 10%)

Just to complete this post, lets write some examples of Contextual vs Composable:

-GUI Vs Terminal
-Framework Vs Programmatical approach
-Wizard Vs copy&paste files into directories

As a conclusion, all I can say is that the decision on which design to go for, will depends on the type of user you are dealing with.

Resources:
-http://gigaom.com/2013/02/16/devops-complexity-and-anti-fragility-in-it-context-and-composition/
-http://nealford.com/memeagora/2013/01/22/why_everyone_eventually_hates_maven.html
-www.google/com