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.

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.

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.

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.

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.

What’s the difference between Simple and Stupid in interview code?

Kent Beck (I believe) said: “Do the simplest thing that works, not the stupidest”. What does that mean in the context of showcase code (i.e. code you have written as part of some kind of application process)?

Well firstly think of what the point of showcase code is. What is the reviewer looking for as part of the application process? They are looking for evidence of a train of thought or method of problem solving that chimes with the kind of thought processes that they think are effective. Ideally these would be the “best” processes but you have to accept that a lot of processes are about finding people who agree with what an organisation thinks is best practice rather than respecting originality and clever solutions. You should never try to tailor your showcase code to an organisation because it is too hard to double guess what someone is looking for. You can only express yourself as clearly as you can and hope that it fits well with what is being sought.

A good piece of showcase code will appropriately abstract the problem being set, illustrating the way the candidate finds solutions to problems. It will neither be too elaborate, abstracting too much of the problem, nor too literal, coding “between the lines” of the problem being set.

Let’s take an example. If the problem is to model a set of automobile configurations in an object then the problem set may explain that a car is sold with seat configurations of 2, 4 or 6. In my view a stupid solution would be to have a list of just 2, 4, 6. Clearly the reviewer is going to want some flexibility here, the solution should be able to deal with a new configuration of 5.

An obvious solution is to just model the number of seats as an integer value. You can encapsulate the data by providing an API that allows you query how many seats a configuration has and provide a way of setting that value in an immutable way (once a configuration is set then the number of seats it has is unlikely to change in the lifetime of the object, that’s simplicity not stupidity). This solution just exposes that a configuration has a number of seats which is an integer, which is logical. It is an entirely sensible solution that keeps it simple.

How might a nervous candidate overcomplicate this situation? Well the number of seats really is immutable unless the problem set says otherwise, you don’t need to supply a mutator. Similarly the number of seats is never going to be a Real number.

What about modelling the number of seats as a list of Seat objects? Well yes that works because the encapsulation should hide the implementation and the number of seats is now just the number of Seats in the Seat list. Domain-driven design fans might even say this is a better solution that an integer because it is a closer description of the domain. However I think that simplicity would tend to demand that until we have something else to model about a Seat (say, whether it has a seatbelt) then it is hard to justify having a class whose only purpose is to be counted in a list. For all the difference it makes I could put Turtle objects into the Seat list. In terms of showcase code using this technique actually gives the reviewer a bit of a headache because instead of just ticking the box and moving on the reviewer now has to ask whether the new level of abstraction introduced is valid or not, is it a good idea to have a class with no functionality or data? What if actually the seat configurations are better represented by enumerated constants? The effort of creating the Seat class is just wasted and has to be replaced.

This solution at least stays within the bounds of an existing paradigm. If a candidate starts to abstract wildly then reviewer is going to give up in frustration. If the candidate starts abstracting the model to the point where it could model a motorcycle or truck just as well as car then they have just failed the process. Unless the problem says something about having a motorcycle then you don’t want to see Vehicle With An Engine type classes. After all if you start to generalise then where do you stop? Sure you can model a motorcycle and a truck but why not a plane? Or a rocket?