robjam.es

How do you know when you are finished? This can be quite difficult.

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”!

Technical Debt is a concept that was introduced in Agile project delivery as a way to understand how to make better software development decisions. I think it’s just as relevant in any technology based decisions.

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.

2012 has started and so has my 5th month at Echo Entertainment, and I must admit, I’m having a ball!!!

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!!!!

Came across this really interesting infographic about customer retention. The focus is on gaming, but at a high level, the key points are critical and most often forgotten.

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/

Enterprise Architecture is an important practice that has come out in the last 10 years. To me, its an attempt at the ‘grand unified theory‘ in business & technology. And of the most important models within Enterprise Architecture is to derive the Business Architecture which sits at the top of this tree. After discussing this with a number of people, I have got some traction to a concept I have been talking about for a while that I call it the “Architecture Deck”.

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.

I have been involved in some interesting conversations recently, where technical founders are struggling to find business co-founders and vice versa. Additionally, there seems to be the search for the holy grail of what defines an effective founder. Everything from age analysis, to combinations and structures. But I wonder if there is a magic bullet theory that could be derived here?

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?

When solving a problem, we come across what seems the most obvious issue, and fix it. We then assume that the problem has gone. But there are many instances when there are a deeper set of problems that don’t appear so obvious.

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.

I'm a huge fan of the feedly reader in my browser. But there is something that has been driving me crazy. I constantly get unread messages that are entirely unrelated to my subscriptions, and I'm a bit of a stickler for making sure my inbox is cleared – including my RSS feeds, and I am very specific to what I subscribe to.

Google Reader (and consequently Feed.ly through its support), have the Social Capabilities built into the app, which is all about showing relevant posts from people in your social network and buzz posts. But not clear way to turn this off!!

I finally found out how and its quite easy!

1. Log into your Google Reader account and go to the reader main page
2. type the following into the URL bar and hit enter: javascript:antisocial('true')
3. That's it!!!

You will no longer get posts from Buzz or feeds that you haven't subscribed to!

Sometimes you need to change the Session Timeout in your grails application. But the important thing to know is that its not really an attribute your application supports, but its something that you can tell your container to change.

To do this, you need access to your web.xml file, which is not available by default. First run;

grails install-templates

Then you need to edit "src/templates/war/web.xml" and add or change after servlet-mapping;

<session-config>

   <session-timeout>60</session-timeout>

</session-config>

The value that you pass in the session-timeout is in minutes. And you're done!

Today I went to Qantas’s 90th Birthday party at their Jet base in Sydney’s Mascot Airpot. John Travolta, the official ambassador for Qantas, was there along with a showcase of Aircraft that staff and friends could work around and through. Aircraft such as the original Constellation, the 707 V-Jet (John Travolta’s Personal Plane now), 767 and the might Airbus A380!!!

Here are some photos I took today.