I Really Don’t Know

How long to change culture

Over on Tiny Drops of Knowledge (the name belies the depth of the content) Lyndsay posted about changing culture - in his case being part of a team moving from VB to C#.

At Talis we find we’re constantly changing, and have been for longer than my three years here. At Talis that change has been about talent, responsibility, empowerment, achievement, learning, fun and real values.

Lyndsay says:

A reoccurring challenge we’ve faced on this project is re-learning how to write software. Its more than just learning a new language, tool or framework, its more like loosing the shackles of apartheid.

Over the past few years I’ve concluded that this is the normal state of affairs. When I first started work I was given some great advice - my boss told me, when I handed my notice in, to make sure that wherever I went I wasn’t the smartest person there. What he was getting at is the need in me, and many of the people I count as my closest friends, to be constantly finding out new things. I thought nothing more of it at the time.

But then, working with folks at Talis I realised the very real truth that “the more I learn the less I know”. And I’m okay with that. Not everyone is, but I think it’s key to being as productive as you can be. The change Lyndsay is talking about may be the change from writing instructions for the computer to modeling a problem for yourself and your colleagues. Once you’ve made that leap it makes sense to understand as many different ways of modeling problems as you can - at work we’ve been through OO design in Java through procedural code in PHP and functional code in XSLT to discussions of the similarities between Prolog and how we initially perceive how we might work with RDF.

There’ll be something else tomorrow. I know there will because I work with a load of people who are smarter than I am.

Technorati Tags: software engineering, talis

There’s no I in Team

Back in June on The Berkun Blog, Scott’s talked about Asshole-Driven Development, and other great techniques for the dysfunctional office. He states clearly that his list is cynical, and that there is probably a happy list as well…

Well, I figured I’d take a pop at a happier list…

First up, let’s have:

Motivated and Empowered Individual method (ME,I)

This is how I’d describe the way Joel Spolsky has set up the guys at Fog Creek. Essentially the team breaks the solution down into parts and gives a part to a person. Each person is free to develop in their own way, within some bounds set by the team, and becomes the owner of an area of functionality. Without the distractions of other people working on the same code areas the owner can become very productive within the bounds of the code they own. Joel describes the people he hires as “Smart and Gets Things Done“, he wrote a book of the same name.

Smart Friends Development Model (SFDM)

I spotted this one at XTech in Paris earlier this year. There I met three smart friends who, in their spare-time, had developed Quakr. Friendship in a development team provides a real boost to the way the team communicates and negotiates decisions and issues. In the case of Quakr they were friends first and decided to build Quakr second, but I’ve seen teams formed by other companies where effort has been put in to building great friendships.

Very-Clever and Nice People (VCNP)

Martin Fowler of Thoughtworks is open about trying to hire only the very best people. The main barrier to growing Thoughtworks is finding and hiring that talent. Once hired, they move people around, making sure they get to know all the other very clever people they’ve hired. Being clever isn’t enough though, they also looking for soft skills; they hire nice people. The end result is that they can form teams who can work at a very high level and have a lot of fun sharing ideas and helping each other. This is essentially what Microsoft did in the early days too and how they came to have the Program Manager role. Comments over at Scott’s piece talk about responsibility without authority in a very negative way, but if you have very clever and nice people this can clearly work and Thoughtworks show this with their teams.

Smart and Nice Entrepreneurs (SANE)

Back at Talis we also hire smart people. We also try very hard to make sure they’re nice too. We think we’re all pretty nice really. But there’s also a key self-motivational quality we look for; the ability to understand and be interested in how the software will make someone’s life better, as well as how clean the code is under the bonnet. We think that combination is what’s helping us develop some really great stuff and have fun doing it.

It saddens me to read posts like Scott’s and the subsequent comments. I’ve had bad experiences with employers and managers who seem to have different motivations and values to mine, and I know from friends around the industry how prevalent the problems Scott and his commentors talk about are. Surely the best thing to do is to find somewhere worth working and move, or as Martin Fowler apparently said “If you can’t change your organization, change your organization!”

I had hoped to get to more than three happier methodologies. Perhaps that’s a sign that the cynics are right.

Technorati Tags: software engineering, talis

Re-Use is hard

Bloody hard.

Well, at least it seems to be. So why?

We’re better off than most at work. We hire really smart people, we’ve got good tools and we keep our working practices under review so we can get better all the time. We’ve solved many of the problems that seem to plague software companies (and have a whole new set all of our own ;-)

So why, with a whole bunch of really smart people working close together on similar projects using the same technologies do we not have near perfect re-use?

By re-use I mean proper re-use - of packaged libraries of code - not simply copying and pasting code someone else wrote already. Copying and pasting is easy, you don’t have to think about dependancies, or clashes or what they might change about it in future. You can alter it in subtle ways that make it ‘neater’ and ‘more understandable’. I put those in quotes because they’re subjective measures, what’s more understandable for you may not be for me.

And there lies the nub of the problem. If we’re writing code that others can take and re-use we have to write in a way that matches the problems they’re trying to solve as well as the one we’re solving. And that’s the hard bit.

The reason it’s so hard is that we have to put all the modeling we have in mind for the current problem to one side and start modeling from scratch in a different, more abstract and generic way.

Thinking about it from an OO perspective, books such as Domain-Driven Design by Eric Evans and Object Thinking by David West lead us down the path of using nouns from the domain to name our classes, but when we do that we have to decide which domain we’re currently in. If you want to build re-usable UI controls then your domain is the UI, so nouns like ‘TextBox’ make sense while nouns like ‘Author’ do not - if you want the components to be reusable that is.

In essence that’s where the hard bit lies; in identifying the different domains and how they should be cut so that they can then be recombined in different ways.

So how to get better at that? The obvious thing to do is go look for places where people already solved the problem - that turns out to be class libraries like MFC, the .Net libraries and the swathes of small, open-source libraries that do just one thing well.

When we look at these we find they’re broken into modules, components, namespaces or some other unit of packaging. Within each module the vocabulary is consistent, complete and, to a great extent, independent. This means that a library for parsing RSS may depend on one for parsing XML, but is unlikely to require other packages. This sounds obvious when written down, or as you read a book on it, but when writing the code itself it’s hard.

So, knowing it’s hard, the next most important thing is to support the evolution of the components, otherwise we have to get them right first-time which seems unlikely. This requires forgiveness and respect. The thing you want to re-use won’t have been written as you would have written it yourself; and at that realization you have a choice of two paths.

The first and most common route would be to get a bit ranty, copy & paste the code into your own world (where you have absolute control, so don’t need to be considerate) and start hacking it into the shape you want for the problem you’re solving. The second is to take a deep-breath, put on your reading glasses and start to try and make your head think the way the original author was thinking - if you can achieve that then you can go on to improve the code, extend it sympathetically and contribute that work back. The second route is harder, much harder, than the first.

But even knowing that, it still looks hard to me.

Technorati Tags: code reuse, software engineering

Cause and Effect

For those reading outside of England…

We’ve just had the first run on a bank in 150 years - Northern Rock has been forced to borrow billions of pounds from the Bank of England. It’s been really interesting to watch.

But what’s really interesting is the discussion of blame. Here are the reasons why the Northern Rock went down according to their senior management:

• The Bank of England refused an earlier rescue loan
• Another major bank backed out of buying/bailing them out
• The wholesale money markets closed
• The BBC announced that they needed an emergency loan before they had an official comment ready

What’s notable about these are that they are not the reason Northern Rock went down. That’s plain and simple that they had an imbalance between how much money they had in deposits and how much they had tied up in non-liquid assets. This happened because there was an imbalance in priorities throughout Northern Rock culture that led to them being great at lending money and not as focussed on bringing it in.

The reason I find this interesting is that it ties in with other thoughts I’ve been having about root causes.

The things that the Northern Rock managers are bringing up in their defense are all things that didn’t help, and maybe if some or all of them had been different there wouldn’t have been a run on the bank - maybe.

We’ve been talking at work about why nobody seems to really effectively achieve code re-use and several reasons come up again and again. Deadline; too hard; component not good enough to re-use and so on.

But, as with Northern Rock, I think the main reason nobody really effectively achieves code re-use is because there’s an imbalance in priorities throughout our industry that leads us to be great at producing new functionality and not as focussed on sharing capabilities.

Technorati Tags: code reuse, software engineering

Tidy or Organised

Rachel Davies (she’s a top-notch agile coach if you’re looking for one) discusses the term refactoring and suggests it may be unhelpful.

She suggests calling it Tidying Up instead as then it’s clear what we’re doing.

I agree with Rachel whole-heartedly that the term is somewhat grandiose when talking about the work with non-technical project members, but I don’t think it’s just tidying up - it’s organising.

› Continue reading

Dirty Thieving B*st*rd

Yesterday at work I was having a pleasant few minutes chat with Nadeem over coffee - a break from refactoring our acceptance test suite and we go talking about Gordon Ramsay’s Kitchen Nightmares. A subject close to my heart as a when Ramsay first started doing Kitchen Nightmares a colleague compared him to me, while reviewing code.

Like Ramsay I am passionately against over complicated things and that sometimes means I come across a little strong.

Anyway, we finished up with me saying that I was going to blog about it, so what do I find when FeedReader opens up this morning?

Very nicely written Nad.

Things are always the way they are because they got that way.

How things got that way

Andy Hunt’s (Pragmatic Programmer) blogs a quick post about how “things are always the way they are because they got that way”.

I always try to look at what I am checking in and ask “does it improve or weaken the overall codebase?” I’ve never come across a situation where the honest answer is that my contribution is neutral; I’m either improving the code for the next person who checks it out or I’m making it worse. If the team all make the code just a little worse each check-in it soon adds up.

Usability for Programmers

At work we have a geek book club, a little while ago we all read Joel Spolsky’s User Interface Design for Programmer’s, which is a longer, printed version of this earlier online work. Joel does a great job of explaining the basic of use interaction, provides a few rules-of-thumb and some well-written anecdotes.

What’s struck me back in the office, though, is that the phrase can be read two ways, as teaching programmer’s how to design interfaces or about how to design interface that programmers will use.

This set me thinking about other stuff we’ve been reading, lie Paul Graham’s Hackers & Painters, The Pragmatic Programmer, Object Thinking Code as Design and other bits and pieces. A common thread of all of these is that writing code is about describing a solution to a problem, rather than simply providing a set of instructions to a computer.

Then this week a few of us were working on checkout and build processes for one of our newer codebases, trying to make it easier for ourselves to work on and it struck me that we were really designing software for each other and that a big part of best-practice and common approaches is really just about usability and interactiopn design.

Take, for example, any one of the popular c/c++ open-source applications and you’ll find it has an sutomake based configure script which generates a makefile that has ‘clean’, ‘build’, ‘all’ and ‘install’ targets in it. i.e. it follows the standard pattern. This is no different to using standard menus, buttons and other controls in a Win32 GUI - it’s easier to use.

So, mental note to self:

Consider anyone who will be working with code I’m writing as a class of user and design the development interface with as much care as the user interface.

Google TechTalk: Open Source Performance Testing

Goranka Bjedov - Using Open Source Tools for Performance Testing, Google TechTalk, 8 September 2006.

Goranka provides a great overview of how Google are doing performance testing

“solving problems by just adding more machines is contrary to our mission statement, which is, ‘let’s try to conserve resources’. Make sure you can always throw more machines at it, but eventually you run out of space, you’re usng too much electricity and it’s just the wrong thing to do.”

Performance Testing

“So any time you run a test and you’re actually measuring how quickly a system responds to work load - that means performance test. So, in a sense, you’re answering the question, given a load x, how fast will the system return the result, right? But the important thing is I’m really interested in the time. That’s what I’m measuring.”

Stress Testing

“Like, in the case of a stress test, what I’m really more interested in is when will the system fail and how will it fail. I don’t necessarily care about how fast the response times are, but hwat I really want to know is under what load will the system fail. And hopefully it’s going to do so gracefully.”

Load Testing

“Load test, for me means, I’m putting certain load on the system and what I want to find out over a prolonged period of time, how will the system behave. … But in general for my load tests, … we try to use about 80 percent of the maximum load that the system can handle and see what happens if we’re running the system under that load for a long period of time.”

Benchmark Testing

 ”And so a benchmark test, most important to us, is … it’s simplified, it’s measurable and it’s repeatable, right? Those are the three things that are very important to me. … But basically what bench marks [mean] to us is, let’s try to figure out what the customer or other users are doing out in the real world and then klet’s extract some subsystem or subset of those operations that we can reasonablt, easily recreat and that reasonably well represents the behaviour of the system. And then every single time we make a code change, lets’ run that benchmark and find out, did we mess up the system to the point that it’s unusable or did something really change tremendously. So we tend to do a lot of benchmark testing.”

Scalability Testing

“And scalability means, if I increase a paricular resource, for example, on a typical system where I may have clients and then some frontends and a load [balancer] in front of them and then backends and so on. What if I have 5 frontends as opposed to 10 or as oppsed to 15. If I double the number of frontends, how will my throughput change? … So, some particular variable is being changed … how does it affect the performance of the system or the throoughput of the system …”

Reliability Testing

“So basically, reliability testing - and I honestly believe that yuo should run it on pretty much any product that you have, and run it for at least 72 hours and find out how is your system handling the load? You’ll find out strange things happen.”

Availability Testing

“Availability testing is tied to reliability testing … when people talk about four nines, five nies and so on, that’s what they’re talking about. Availability testing is something slightly different and it basically says when a system fails how quickly will it come back up. … So availability testing tells you , okay,  so finally something has failed, but can it be back up online very, very quickly.”

Very good talk.

Object-Orientation

There are a number of things that I look for in assessing if code has been written in an object-oriented way or in a procedural way - I’ve got a document somewhere that I wrote at a previous job, but this brief piece about “getters” by Martin Fowler is well worth reading.

Fowler assumes a fair amount of prior knowledge in his writing. For example, for this piece to make sense you need to know that “getters” is a term used for methods on Java classes that simply expose a field on the object.