You are working on something and you need to get that deliverable finished; a document, a piece of code, a project, a building or a Lego creation. But when do you now you are done?

This can be extra hard if you consider yourself to be a perfectionist!

There are a four rules that I would suggest to follow;

1. Visualize “done” from the start. Before you get started define what getting it done means. What is that end state, and ask yourself the question “could I get to ‘done’ earlier?”, “what compromises can I make to get finished sooner?”
2. Use tools to test being finished. Test Driven Development does this well. Coders are encouraged to write tests that only confirm the required functionality has been delivered. This discourages over-engineering. Once the tests pass, you’re done!
3. Assess as you go. This means asking yourself whether you are ‘really’ finished, or do you have more to do. What if you stop now, what are the negative impacts, and how much value are you providing by doing the extra work on this ‘thing’? Would there be more value moving onto the next ‘thing’?
4. Accept the 80/20 rule. Accept that it takes 20% of the effort to get to 80% of the finished product. Is it really worth spending that additional 80% of your time, to fill that final 20%?
5. Leave something to do. There is always room for improvement, but make that assessment after your product has been used, your document has been read, or your room has been lived in. You will never get it 100% right the first time round and once you start using your deliverable, you will find ways to improve.

There are of course some exceptions to the above, and you also need to question whether what you are currently working on is one of those exceptions (brain surgery comes to mind, you kind of want to get that perfect the first time!)?

But imagine how much more productive you could be if you could commit to finishing things earlier?

So hurry up and get to “done”!

So much so that I propose that there is a mathematical formula to explain it.

The first part of the equation describes that the more strategic decisions you make and less tactical, the less it will influence the end result (smaller number). But you need to understand that time makes technical debt worse, so that needs to be added as a multipler.

But what is technical debt?

We are very familiar with the concept of borrowing money to buy a car or a house. In a perfect world, we would all have enough money to buy that house or car outright. To do that, we need to save up the money. To shortcut the saving aspect, we go to the bank and borrow money to buy things now. But there is a cost; it’s called interest. You pay the bank back, and when you do, you need to pay interest, the longer you take to pay, the more interest you will pay.

It’s no different with technical debt.

Your options are to take your time and do it right (strategic decisions) or if there is urgency and you want to shortcut the end-state, you do what you need to do, making compromises for the long term vision (tactical) decisions.

You also need to add the complexity of time (interest) to this, because the longer you live with a tactical decision, the harder it is to leave it. This is because over time you will get more users dependent on the system, more data in the database to migrate, or more of other systems and processes dependent on it.

Is there anything wrong with making tactical decisions and inheriting technical debt? Absolutely not! Just as borrowing money for a car or a home you must pay it back, same applies to your technical debt. At some stage you need to pay that debt back. It will cost more to decommission it, to replace with a strategic system or migrate to where you want to be.

The issue we have is that many times tactical decisions are made not realizing that there is a debt to pay off. That is what needs to be highlighted. Use the formula above to communicate it to your business stakeholders.

For those that don’t know, Echo Entertainment was the result of a demerger of the casino business in TabCorp. We own & operate 4 casinos in Australia; The Star in Sydney, Jupiters on the Gold Coast, Treasury in Brisbane & Jupiters in Townsville. Although our core business is casinos and everything gaming related, we as IT, pretty much run everything; casino systems, hotel systems, restaurant, point of sale and even car parks. This is what makes it fun, you have so much variety.

The other thing that I totally love about this place is how we behave. For a public company with over 9,000 employees, we behave like a startup. I was recently part of a project team that delivered a production  mobile application to the gaming floor staff from inception to production in 5 weeks! That is an insane pace, and it was a pleasure of a project to work on. We are process light, which also means that we are bureaucratic light, and that makes for an enjoyable work environment.

I plan to post a lot more about what I am working on. My goals for the next 3 months is to set strategic plans and roadmaps around Mobile, CRM & Gaming systems. Watch this space!!!!

Click to Enlarge

Source: From the great mixpanel blog on gaming, http://blog.mixpanel.com/2011/09/16/infographic-what-you-should-know-about-visitor-retention/

Just a reminder, there are 3 layers to our deck;

1. Foundational – The core and basis that we have to work with
2. Functional – The tried and tested solutions
3. Innovational – The things that make the solution different or special

If we try and correlate this to the human body, or more specifically a component of the human body such as the legs. This may be described in the following way;

Foundational

If we look at the human legs, there are some very specific core capabilities that they have, such as balancing upright, being able to move a person around and the materials that are used to construct them; carbon based, organic material to create skin, bones, muscles, nerves and the blood that fuels the cells. This is foundational as its core to the human legs. And the observant ones out there would have recognised “well, that’s not unique to human legs!?” And how right you are! This is a great example of the core capabilities that most animals with legs have (give or take), and so we are working with something that has been proven. The “give or take” takes us to the next layer; functional.

Functional

Human’s can walk, run, jump and do a variety of different things with their legs. But there are some tried and tested methods that have been employed. For example, there is nothing stopping you from walking backwards with you legs wide a part and feet pointing outwards (granted, it would be difficult). But the point is, we humans typically don’t walk that way. We have adopted ‘best practices’ in walking, we use our hips, bend our knees, put one foot in front of the other etc. So although there are many ways to handle movement with our legs, to get the most optimised functional movement from them, we adopt this best practice.

As an aside, think of the down stream benefits here. Pediatrists have been treating well known issues based on these best practices, how do you think they would go treating you if you always walked the way described above? Shoe’s are designed based on this premise of walking. There are many other support benefits.

Innovational

So what are the exciting innovational aspects that we can attribute to legs? Firstly, the fact that humans effectively walk upright, which would gives us the competitive advantage against certain other animals. But that is not fair, we should compare apples with apples. So think about the well oiled machine that is an sprint runner. Their muscles are finely tuned for explosive strength that is converted to speed. This is different to a marathon runner that is focussing on stamina. Sprint runner’s bones are strengthened, and the the other systems in their body (lungs, heart etc) work hand in hand to provide this competitive advantage. Although they may have the same make up, they have innovated in how they train and focus on key parts of their legs that sets them above others.

Can you think of other examples?

The Architecture Deck is a framework to try and conceptualise the layers of an architecture that helps make business decisions. What is great about this deck is that can quite easily be used to architect a city, a house, an enterprise, a startup, a team or a product, or absolutely anything that  can get value from an architectural blueprint.

I’m a big proponent of simple models, and this is about as simple as they get, but you will see in the next series of posts, how it is quite powerful.

Lets start today with explaining the layers (from the bottom);

Foundational

This is the lowest part of the deck, and it describes the most foundational aspects to an architecture. Its where tried and tested, and industry standards (beyond best practices) are employed. You will 99% of the times, engage this in your architectural solution, as there is no benefit to your architectural model to go outside of this. Examples would be the need to have sewerage in a city plan, or cement slab for a house, use IP networks to interconnect computers in an office environment, or use a relational database for storage in a software product. Sure there are other alternatives, but for your current purpose, there is no benefit to go outside of this. This will be described in more detail in future posts.

Functional

The functional layer describes the aspects of the architecture that have many differentiators or competitors, so you have some choice. But this is isolated for 2 special reasons; a) things here do not provide your city, business or product with a competitive advantage, & b) in immature architectures where this is not articulated, every architecture has their own version of it. This is critically important, as what we are trying to identify here is the concept of engaging best practices. Examples here could be a Rail Network in a city, the type of timber floorboards you put in a house, the order process in an enterprise, or software pattern you use in your product. As I’m sure you have already realised, there are many choices with all these examples, but the question that must be asked, “Is there any advantage in trying to be unique here, or are we best to use the methods that others have tried, tested, failed and then got right?”

Innovational

This is the most exciting layer!! This describes what makes your architecture different. What makes New York a great city that others try hard to imitate, why everyone in your street wants a house just like yours, why your office can process sales orders faster than anyone else, or what makes the iOS such a unique OS for Apple that everyone is imitating it! Its the competitive advantage, its the unique streak, and its the innovation that occurs in a city, house design, office operations or software product!

I appreciate that this is all quite esoteric, and the details will come out in future posts, but essentially the basics described here are all that you need to help you make decisions. In future posts we’ll get into the details, we will also look at some real world examples, and we’ll discuss how you can work out your own Architectural Deck.

In my limited experience, these are the elements that I found critically important.

1) A respected and aligned knowledge base

Maybe unusual to be at the top of my list, but I believe this is one of the culprits for many relationship breakups disguised as other things. Take the case of a technical and non-technical cofounder, one must respect and trust the other’s knowledge and experience. As a non-technical founder, if you are questioning every technical decision that your partner is making, you are doomed for failure. But this trust needs to be earned. You need to make decisions your partner’s and your team will respect. As soon as you do something that smells of something different, that respect is not only lost, but everybody’s motivation will be channeled into something they think is more important, and it not you or your startup.

2) Equalized commitment

This is not about a 50/50 split, but about the commitment each of you are willing to provide. Do you agree that once the business is sustainable, that you may have to give up your day jobs? Do you have alternative agendas going on, or does one of you see this as a pet project while the other is banking his whole life on it? Nothing wrong with any of these scenarios if you discuss this prior and both agree the arrangement you are entering into.

3) Strategic alignment

One would argue that this is the no# 1 important aspect. That you all agree what the strategic direction is. What is going on in your head is agreed by everyone, but this may be only your perception. The best way to tackle this is through your existing strategic discussions, but don’t forget to try and do some crystal ball gazing. Ie/ when toting out your grand plan, start asking some ‘what if’ questions; “what if we run out of money in 18 months?”, “what if someone offers to acquire us in 12 months, but at a fraction of our expectations?”. See if you are all on the same page in the early days with these types of decisions. I would also recommend you keep notes here – believe me, people’s attitudes change when real money is being thrown around.

4) Clearly defined and accepted responsibilities and accountabilities

This is almost business management 101, but I have seen so many disputes occur because there was no clear concept of who should be doing what. “you mean you expect me to write the monthly newsletters?”, “when did it become my role to go out and do sales?!”. Remember that “accountability” is the decision maker, while “responsibility” is the doer. If you have not used one before, I love using RACI matrices for this.

5) Vito power

This is a hard one, and I struggled to define it. But what happens when you are just totally at odds as to what the decision should be? The rule defined above should help here, but it’s the big strategic decisions that I am talking about, most specifically “time to pivot”! When one founder believes that the current model isn’t working, and it’s time to change, while the other founder is convinced that the existing one has not been exhaustively tested and we should persist. This is a critically important decision, but who wins? The best path you have is to try and argue your case and persuade the other side, and I encourage that this is done until all avenues are exhausted. Failing that, someone may have to pull the Vito card. But keep in mind, its not going to be pretty if you do!

Anything else you want to add?

Take for example debugging code. When it is determined that there is a bug, we may go through the code and find something blindingly obvious to us that is the problem. We may then do the rights things; write a test that checks for this, fails and then we fix the bug and push to be deployed. Woila! Problem fixed! But is it?

Many a time, this assumption can get us unstuck. We should actually check whether there was more to the problem. This is particularly true when we have technical solutions to business problems, as there is a translation in between.

A friend of mine is a telco line engineer, and on a number of occasions he has mentioned that junior engineers get unstuck when they go and service a faulty line after heavy downpour of rain. They make the “assumption” that since there was heavy rain that the line terminals are flooded with water. They go onsite, and sure enough find moisture in the terminal plugs and clean these plugs up and replace it all. Only to find that the issue is still there.

This is because that although the cables don’t like water, they are actually quite resilient to these conditions, and its usually other unrelated issues, such as pressure building up in pipes that cause issues with the cabling itself elsewhere. And its this information that an experienced engineer knows to look out for.

For those of you that don’t know; Searchable plugin is a plugin wrapper in the Grails Framework for the Compass Search engine that abstracts much of the domain class to search index mappings. And Compass is an extended implementation of the robust Open Source Lucene search engine. But its the “Domain Model to Search Index” abstraction that has cause for concern.

So lets start – I think Searchable is absolutely brilliant!!! It simplifies the process of adding a search engine to a Grails application. Although apart from some straight forward indexing and searching, I don’t believe its designed to handle complex search scenarios. Sure, you can spend a lot of time bastardising your application to support many of the elements (such as searchable component and searchable reference) to try and get deep nested relationships correctly mapped, but more often than not, I find myself also bastardising my domain model to handle what I want search to do!!

I will continue to use searchable for basic type search mappings, but I have recently decided that it is more efficient to separate the concerns between domain data and search indexes. Domain models are inherently a tree structure, there are relationships, abstractions and extensions. Whereas your search index is a flattened version of this. And trying to do this flattening through decorators and mapping files is not effective.

In a recent project, I took the approach to handling the domain to search indexing data structure conversion myself. And its already started to demonstrate pay offs! I have moved to the Solr Search engine, which is another emerging implementation of the Lucene Engine. I favour it these days for its added features particularly in Geo Spatial Search capabilities.

Quite simply, my application has a SolrService that takes domain objects that I pass it and convert them to a flattened Solr Object (that I also implemented), that is then passed to the Solr Search Engine through SolrJ. All this is quite simply managed through the afterInsert, afterUpdate and afterDelete triggers in the Domain objects. But it means that I don’t have to write complex mapping files to try and map my domain structures to the search index I want to create.

What are the benefits? Most of you would state that it would take more time doing this, but I found it to be the contrary. I have spent so much time (sometimes weeks), tweaking searchable configurations and mappings to see how it would affect my index. Looking at indexes with the Luke tool to try and determine what is actually going on and then trying to perform searches against that data to see if I get back what I am after.

I have found that the search indexes are much smaller and much more performant because of it. Because you have much more control over the indexes, I create my indexes so that I don’t have to do any GORM queries at all when rendering search results. Which you can also do in searchable, but its much more complex to understand the translation.

Soon I will try and post some code on how I actually did this.

Although JQuery has a great .clone(); method, all the examples talk about cloning and re-inserting without modifying;

ie/ given the follwing HTML,

[code language="html"]
<div class="group">
<div class="user" id="1">User name</div>
</div>
[/code]

you can do this;
[code lang="js"]
$('.user').clone().appendTo('.group');
[/code]

But what if you want to do somethnig to your cloned object before re-inserting it into the DOM? Sure, with the above example, this can be quite straight forward, but other scenarios can be a little more complex.

I discovered that the best way to do thia is the following;

[code lang="js"]
var $clone = $('.user').clone()
$clone.attr('id','2')
$clone.html("Other User");
$clone.append("(User Title)");
$('.group').append($clone);
[/code]

Pretty straight forward, but the main gotcha, is how do you traverse this ‘in memory’ DOM tree? For example $clone.$(‘.someClass’) won’t work. And this is where the .find() function is your friend!

You can simply do;

[code lang="js"]
$clone.find('.someClass').doSomething();
[/code]