Tag Archives: Work

Work

Google Apps and App Engine

If you use Google Apps to provide you with email then you should also really be thinking about enabling and using Google App Engine as well. Internal applications are much easier to deliver to the business as a whole and having a ready-made platform makes it easier to try out ideas that previously would have been impractical.

The first advantage is that Google Apps that are bound into your domain allow you to create something that is easy to access for an existing user (no additional login is required) but also gives you peace of mind that you are exposing virtually zero surface area for attack.

The second is that for Python at least it is easy to access a very full featured environment with a minimum of code. Want to send emails, have task queues, access to memcache, serve static content? It is all a YAML configuration line or import away.

I love services like Heroku but a lot of internal apps have relatively light usage and benefit from the batteries included approach rather than combining various plugins. It makes it easy to switch between different approaches and react to different demands.

Standard
Work

Is this really the manifesto we want?

Silicon Milkroundabout tried to produce a manifesto for why people should consider working at a startup. This is the outcome.

The first time I saw it I was very disappointed. While I cannot knock its authenticity it is a profoundly depressing document. While there are the standard statements about passion and having the freedom to make what you should rather than what you are told to; there is much more about poverty, tiredness and scarcity.

If I read this I would say that working for startups is a mugs game. You’re far better coming in during the expansion phase when salaries are higher and the business case better proven.

The many references to tiredness and lack of sleep is also revealing. What I have discovered is that tremendous pressure is put on you to deliver product in a technology startup and this should be resisted at all costs. Sustainable pace is more important in small organisations than in large ones. In a large organisation you can actually burn out a team to achieve a goal because you probably have access to the resources to replace them. In a small one, once you’ve wrecked a team (probably including yourself) you have no way of replacing them and a death spiral will inevitably set in as decision making becomes progressively worse. Remember that a startup should aim to deliver progress not product. Don’t work with people who don’t understand this.

Money, frankly seems to be the missing ingredient from this list of reasons. Maybe adding “because late-stage equity options are worthless” would ruin the overall tone. Many people, especially investors, are involved in startups because they offer potential massive returns in a low growth environment. Americans are much more open and brash (you might even say vulgar) about this with talk of flipping and sale valuations of millions of dollars (often farcical as in the case of Groupon who merely had the bad luck to be caught before their IPO).

Even then this reason is foolish because if what you want is money then you should go to the City. The money is guaranteed, guaranteed in fact by the government which not only underwrites it, bails it out but then charges off into Europe to protect it from legislation that might affect its lucrative tax haven and money “recycling” business. In contrast being involved in “entrepreneurship” is a rather romantic and significantly more challenging way to achieve wealth.

I do work at a startup though and I was at Silicon Milkroundabout trying to encourage people to join me in doing this.

My personal motivation is that for me a startup is a business that is complete but small enough that you can actually see and understand all parts of it. The interesting thing is that organisational dysfunction is actually just a likely in a startup as a larger firm. Often the problems are actually exactly the same, simply orders of magnitude less significant.

Being able to pull the curtain aside is fascinating. Working in the small also removes the mystique that gathers around things and people that generate large revenues. Once a certain number of livelihood’s become involved in a particular process or product you lose the ability to tinker with things or even to question why things are the way they are. In an environment with no money and no customers any change is either positive or at least neutral.

Working in a startup for non-cynical reasons means creating something that is of profound personal interest. I really am interested in trying to remove friction from the process of turning ideas into reality. Wazoku is a product that I do believe in and what I was saying to a lot of people at Silicon Milkroundabout was try the product. If you are interested in solving the problem and the solution in turn solves some of your problems your work is satisfying at all levels. If there is not a satisfactory solution already in progress for your problem then a startup is the only way that you can initiate that process of moving to a more perfect world.

Working for a startup is a last resort; need should be part of your motivation; ignore idiots and their advice; make sure you get enough sleep.

Standard
Work

The Pretentious CTO

I currently use the title CTO in my job despite the fact that I only directly manage two people. A classic example of the “fake” CTO. So naturally I felt a little defensive in a recent discussion with Jon Hartley about why I feel that the title can be justified by people who work in small businesses.

Let’s start with an entirely pragmatic answer: the job title is something that is well understood. While the majority of my activities day to day would be adequately covered by the title “lead developer”, the truth is that technical authority and decision making resides solely with myself. The easiest way to convey that to suppliers and recruitment agents (and stop them seeking to go over my head to my non-existent boss) is to use the most commonly understood title.

I find it ironic that I have managed much larger projects with a much junior title. In terms of experience I do not feel a particular gap with other startup CTOs but obviously there is a bigger gap as you move into the equivalent role in larger organisations. A lot of those people come from non-technical backgrounds reflecting the greater need for people management at larger scales. The number of people who have technical backgrounds and have managed groups greater than a hundred people strong onshore are probably pretty small.

For me the key differentiator in my current job is that I do hold a technology portfolio within the management and report on the whole technical area to the management team as well as the board and investors (although to be honest the latter too are not that bothered so far). I would happily concede the “Chief” as I have no other senior technology reportees but I think it is a different kind of pretension that seeks to do down the unique aspects of a role you have in an organisation. I am an officer of the company and I do make the key decisions for technology and I am held to account for them. CTO is the common title and I am comfortable using it.

Standard
ThoughtWorks, Work

Why didn’t I get into ThoughtWorks?

I had an interesting conversation with a recruiter recently about the difficulty of the ThoughtWorks recruitment process. It’s true that the majority of applicants don’t make it through, but then that it is true of most recruitment processes. The ThoughtWorks one is perhaps more drawn out and longer so you feel that more effort was invested if you don’t go through.

One thing that is quite interesting is that being really smart is not the only criteria if you want to work at ThoughtWorks. Candidates who fail the process often go on to join other very prestigious companies. Why did you turn down this person who went to this other company?

In most cases the answer is that the company they ended up joining was not a consultancy. Consultancy is, unfortunately perhaps, not just about raw smarts and programming ability. Unlike a lot of companies ThoughtWorks doesn’t really have a codebase, the job is mostly about working with and helping people improve their own codebases.

Coaching, persuading and analysing code is quite different from writing good code. My favourite example of this is a code submission that solved all three of our problems in probably one of the shortest sets of solutions I’ve seen. The candidate correctly identified each underlying abstraction and applied the standard solutions in a concise powerful way.

An automatic hire then? No, sadly not, because while the candidate had the time to solve all three problems they didn’t bother to write a single test. If you look at what they did they really just proved their own superiority and left nothing that helped explain, maintain or develop their code base. You could already see that this person wanted to be the hero of the piece, not the collaborator.

In the three years I’ve been at ThoughtWorks there have been several times when I could have produced a much better solution to problems than what was actually created in collaboration with my clients. I would like to think that instead of the best solution we were able to produce something that our client teams understood better than what they had previously, was more productive that what they had previously and was more reliable that what they had previously.

All these things are more valuable than an individual being a better coder than their peers.

Standard
Programming, Work

The beauty of small things

I am very interested in the idea of “constellation architecture” and microapps as new model for both web and enterprise architecture. It feels to me like it a genuinely new way of looking at things that can deliver real benefit.

It is also not a new way of doing things, it is really just an extension of the UNIX tools idea and taking ideas like service-orientated architecture and some of the patterns of domain-driven design and taking them to their logical extreme conclusion.

If I take ls and I pipe it through grep, you wouldn’t find that particularly exciting or noteworthy. However creating a web application or service that does just one thing and then creating applications by aggregating the output of those many small components does some novel and slightly adventurous to some.

SOA failed before it began and the DDD silos of vertical responsibility seem poorly understood in practice. Both have good aspects though. However both saw their unit of composition as being something much larger than a single function. An SOA architecture for payments for example tended to include a variety of payment functions rather than just offering one service, authorising a payment for example.

There is a current trend to look at a webpage as being composed of widgets, whether they be written as server-side components or as client operated components. I think this is wrong and we need to see a page as being composed of the output of many different webapps.

Logging in a web-application whose only responsibility is to authenticate users, the most popular pages are delivered by an application whose responsibility to determine which pages are popular.

This applications should be as small as we can make them and still function. Ideally they should be a few lines of domain code linking together libraries and frameworks. They should have acceptance/behaviour tests to guarantee their external functionality and that’s about it.

It seems to me that the only way we are going to get good large-scale functionality is by aggregating useful, small segment small functionality. Building large functional stacks takes a lot of time and doesn’t deliver value exponentially to the effort of its creation.

Standard
Work

One Year at ThoughtWorks

It’s now been a year since I joined Thoughtworks and  for me a year at ThoughtWorks is like two at any other company I’ve ever worked at. I have learned so much since I joined I really feel like I’m a very different person to the one who joined. I’ve met lots of really smart people who are doing really interesting things but all of whom have been generous and unstinting with their knowledge, experience and advice when asked.

This openess is the thing that really sets the culture apart from so many other firms. Knowledge seems to have value only when shared and people are generally so enthusiatic about the things they know they are really eager to help you understand things. In most companies knowledge is power and hoarded carefully, divested for maximum gain with the grace of a man having a tooth extracted.

The other cultural aspect that has been really different is that there is tremendous peer pressure to be excellent. If you are cutting corners or hacking something that’s convenient but flawed or just riding on your opinion then someone is going to call you on it.

When I’m working on client-owned projects I often think about different approaches and then wonder how I would feel if I had to justify the solution I chose to my TW collegues. It’s interesting because it gives you a strength to stand up against weak solutions and weak answers, even if you’re not actually working with anyone from ThoughtWorks.

So it’s been a good year generally and certainly the best I have had working for a company rather than doing my own thing. However ThoughtWorks isn’t perfect because any aggregation of individuals requires compromise and the biggest problem with ThoughtWorks is how you handle that.

One of the obnoxious things you can come across is the idea that you should be grateful to work for ThoughtWorks (particularly held I think amongst those who have only worked at TW or the City and other consultancies). ThoughtWorks has problems and each individual has to balance the benefits of getting to work with so many amazing people against an organisation that can’t really resolve its central dichotomies. Is it the Employee owned company that is delivering excellence or is it the home to the best knowledge workers who are revolutionising IT?

The trouble with not deciding exactly what the company wants to offer its employees as the vision is that every decision ends up infuriating half of your smart, emotionally invested and highly motivated workforce because it doesn’t fit with their interpretation of the ThoughtWorks ideal.

So it has been a great year and an experience I would recommend to anyone. My closing thoughts about ThoughtWorks is that it is a company that hasn’t said “No” to anything I have wanted to do. There isn’t always a lot of support and it is more forgiveness than permission but I feel that ThoughtWorks has helped me be a better person because it has given me the chance to do things that other organisations simply shut down in an arbitrary and off-hand way.

So thanks Roy and everyone else who works and has worked at ThoughtWorks for creating that opportunity for me.

Standard
Work

Perverse Zen

Sensible companies plan for poor outcomes, great companies plan not just for bad outcomes but for good ones as well. They look at a range of situations that might occur and create some kind of strategy that will guide the reaction should that situation actually occur.

Most companies however exist in a state of perverted Zen where they are so in the moment they literally cannot see a second into the past or the future. If things are going badly then things are terrible, spending is slashed, projects cancelled and all decisions delayed. If things are going well then things are terrific, projects are approved without any sense of due dilligence, money is spent liberally as there is plenty coming in and the current good times are entirely due to the wisdom and good governance of the current management.

The trouble with this Perverse Zen is that it is entirely reactionary and it makes the whole company vunerable to the whims of whatever mood is currently blowing through the organisation. Good companies I have worked for have always had a range of responses to the future. They also went through the effort of identifying what must be done regardless of what happens to economy, to their customers or indeed to the structure of their business.

These priorities then inform what the response to a given situation will be. When times get bad cutting effort to zero is often counter-productive, you want to match effort to your capability to spend. Similarly when times are good it helps to already have a plan as to how to spend sensibly; bringing about the largest and most immediate benefit to the organisation.

Standard
Programming, ThoughtWorks

ThoughtWorks Code Assignments

When you enter the ThoughtWorks recruitment process you are asked to code a solution to one of three problems.

Googling for the answer is clever in the sense they can be hard. It is also really stupid in that the code will be reviewed by at least two people who if they decide that your application will be taken forward will interview about your code and why you have chosen to implement your solution in the way you have.

You won’t be able to tell them that the code is the way it is because you copied it off someone else! So, write it yourself! The feedback you get will be more all the more useful if you code things in your own way. Otherwise the feedback will be relevant only to the person who wrote the code.

One piece of help I can give is that there are no trick questions or mistakes in the assignment paper. If you think you have found an error in the problem statement you have probably misunderstood the problem.

Standard
Software, Work

Offshoring means your job too

I quite often come across a strange attitude amongst people in favour of offshoring development work. It reached a kind of apogee in a recent quote that “The thinking will remain in the UK but the work will be done abroad where it is cheaper.”

Don’t kid yourself! If you outsource the work then you also outsource the thinking. If you are an architect, or a designer and your implementation team is offshored then your work has also been offshored. Without the vital feedback from your implementers your high-level input is very quickly going to go stale. The understanding of how to do a job lies with those who do it, not those who raise the purchase orders.

Don’t flatter yourself! For some reason a lot of people in the UK seem to think that the IT staff in places like China, Eastern Europe and India are incapable. I know from experience that there are more smart people in all of these countries than there are in the UK. It’s a simple case of numbers. Don’t confuse offshoring to a lowest cost bidder with being incompetent. You pay so little for your code that it sends a message: we don’t care about our software. If you don’t care why is the wage slave that is eventually contracted to produce it?

So if you are involved in “higher food chain” work, don’t get caught up in the hype. The thinking will always end up following the doing, and then, ultimately, the purchasing does as well.

Standard
Work

The Dark Side of Employee Empowerment

It is a great thing to empower your employees to make a change within your business. It is another to actually empower them to make change rather than just saying it.

However empowering your employees does not give you a get out of jail free card. To often management respond to criticism by shrugging and saying that if the staff don’t like something then they should change it.

If an employee doesn’t like the strategic direction of the firm they work for they really cannot just go out and change it. The most they can do is lobby and harp at management to try and change direction. If they see little immediate reaction to their badgering then they are quickly demotivated to campaign for changes.

Empowerment does not mean that management should not actively seek feedback and act on it, particularly if change is easy for them to effect. They should also be ready to shoulder the burden that if you empowered your employees and you still have problems then they are still your problems. Saying that employees should have fixed them doesn’t help your staff or yourself.

Standard