Cogent Departure, Part 2

In an earlier post I mentioned that I'd pass on more details of my Cogent departure as they became available. I'm at that point now, but before I can tell you that story, I have to tell you this story (a tribute to my 6y.o. son's Captain Underpants fandom, which is another story altogether).

Twenty years ago, come March, I moved to London. It was the height of Thatcherism, and shortly after I arrived I went to a matinee at the theatre. At the end of the performance someone came on stage to say there had been "a bit of bother" and we should avoid Trafalgar Square. As an ignorant new arrival I didn't know how to do that, so I ended up walking through the debris of the Trafalgar Square Riot. Welcome to London, Mr Hayes! London is an amazing place, with deep history and so many things to see, but the next year is tagged in my mind with impressions of tension and antagonism. I've visited since and found London to be far more pleasant than it was in 1990.

Ten years ago I was working at Goldman Sachs in New York. I was leading one of the best development teams I have ever had and we were implementing XP on a full project - a first for me and a first for Goldman. Early the next year I did something very un-Goldman - I resigned. I used my bonus to pay off my last debt (the mortgage on my house in Sydney), Amanda and I travelled around America (20,000 miles in just over 100 days), then we moved to Melbourne and did as little as we needed to to cover the rent. There were about 6 people in Thoughtworks Australia doing "agile", but they were working remotely on the Caterpillar project, and that was it. I spoke to as many groups as possible about XP, and things grew from there. Essentially this was the beginning of the path that lead to Cogent Consulting.

This year I'm going to complete some decade long cycles. The current plan is to return to both London and Goldman Sachs, as EMEA Controllers CTO (EMEA is "Europe, Middle East, Africa", but from a technology perspective that's Europe). Before anyone gets excited, there are lots of CTOs in Goldman Sachs - I think I'll be responsible for technical direction for about 0.5% of the banks IT staff, and I'll be in a matrix with many other architects. Regardless of scope, I think this is a great opportunity for me and will be a great experience for my family. We're tentatively scheduling a move in April, but plans are on hold pending the tabling of financial services legislation in London that may impact GS staffing. I still plan to finish up with Cogent at the end of March and to take some leave if there is time.

On the other hand, my infrequent blogging and twittering will probably become almost non-existent. GS holds things very close to its chest, now more than ever I expect, and is very careful that random technical comments don't get associated with the GS brand (for either better or worse). Since I'm an expert in random comments I'll need to watch my mouth fairly closely. :-)

If you're in London and you'd like to catch up later in the year please let me know - part of this opportunity is the chance to renew (and create) relationships in the northern hemisphere!

PS. Some people have read this and wondered why I would move to a job in management. At GS architects at all levels code 80% of the time, so if anything I'll be doing less management than I do at Cogent and in my current consulting roles. I suspect a lot of it will be up to me. I still expect to have plenty of opportunities to influence behaviour.

Cogent Departure

With sadness and trepidation I need to tell everyone that I plan to leave Cogent Consulting. I appreciate that you're not supposed to leave your own company, but I've rarely let what you're "supposed" to do govern my career. My departure from Cogent will create a hole, but I'm perfectly comfortable that the hole will be quickly filled. Marty Andrews will take over my role as decision-maker-of-last-resort, and I expect that most people, both staff and customers, will notice little difference on how Cogent runs or the quality of the service that it provides.

The decision to leave Cogent isn't an easy one, but sometimes opportunities come up that you simply can't ignore. I'll leave out the details of this particular opportunity since it isn't finalised, but I believe it's in the "can't ignore" category. It's quite possible that it won't turn out as I hope and I'll be back, but I need to find that out for myself. As my lovely wife said, "If you'd never created Cogent, you would have regretted it for the rest of your life. If you don't try this, you'll regret it for the rest of your life." Or as she said to our son, "would you like to have a family adventure this year?".

I'm very proud of what Marty and I have accomplished to date. We're running a company using approaches we were told were unrealistic, that simply wouldn't work, and Cogent's existence is proof to me that they can work. All the books of the company are open to all the employees, we don't put people on gigs they wouldn't choose to do themselves, and we try to make as many decisions as we can as a group. We share our profits in a fairly egalitarian way, and we've done some product development. We don't do any of this perfectly, but our hearts are in the right place. I'm a little more balanced about the pros and cons of these approaches, a little less naive, but I suspect that Rupert would still call me a Trotskyite. I wish I'd started this ten years earlier.

In many senses, as an individual I'm not important to Cogent. It's the principles, values and quality of the staff that separate Cogent from other companies and help us deliver great solutions at great value-for-money. All of these things will survive my departure. Cogent has always been managed by a small group with contributions from throughout the company, and this will continue. The trepidation I mentioned earlier is for myself, rather than for Cogent.

I expect to finish up with Cogent at the end of March, and I'll pass on more details as they become available.

What would you like in a code quality tool?

Although continuous integration has been a huge step forwards for the development community I think that over time we've tended to treat it as a rather large bucket that we could keep tossing things into. Sure, someone should immediately address that method that's too long, but should it really stop the build and the release of the next version if all the tests pass? My feeling is no, it shouldn't.

I think that the agile community could do more to encourage various parallel continuous processes that test different aspects of the application. In particular, we could separate the static analysis of the code quality from the behavioural analysis that we perform with tests, be they unit, integration or functional tests. If we separate the two aspects then we can look to improve them at different rates and in different dimensions. This separation is the motivation behind an idea that Marty Andrews and Simon Harris have been kicking around for a few years (Marty is the author of Roodi and Complexian, and Simon is the author of Simian, so they have a long-running interest in code quality). Cogent is now planning to turn this into a product - something that you can point towards your source code repository and simply unleash.

We don't have a name for the product yet (suggest one if you like), but it will run static analysis tools (like Checkstyle, Simian, Roodi, Reek, Flay) against each revision of your code base so that you can see trends over time, and it will produce warnings when the values of the metrics exceed certain thresholds. The product will be free for open source projects.

We'll start with a simple, web-based version, probably to run over Ruby projects in public Git repositories (because that's low-hanging fruit for us), but we're going to be very community driven. With this in mind we have a survey that will let you influence the development direction, even before we start. If a tool like this is something that interests you, please fill in our product survey. As a bonus, the first 500 people to complete the survey will get unlimited free access to the product in recognition of their contributions.

Cogent moves forward

Cogent has made a couple of steps forward this week. We'll tell you what those steps are in a minute, but first a little bit of background. Cogent Consulting really started two years ago when Marty and Steve merged their consulting revenue into one pool - now we have 11 employees, and we're going to come close to $2m in sales for this financial year. We generate enough margin to have two people on product development, we've released Runway, and we're about to start on another product venture. We still keep all our financials open and we operate reasonably democratically. Things are tracking fairly well.

So here are our two big steps. Our 11th employee was a business development manager, Rachel Morley. Having a business development manager increases our overheads, but it also gives us a more active, structured approach to business development that lets us (and indeed encourages us to) support more employees. As a result, we're looking for people who would like to become Cogent employees.

Cogent isn't your typical employer. We're interested in the usual things - people who have deep technical knowledge, people who can represent us well on client sites, people who like to learn. You've heard all that before. We're quantitatively different in that regard, in that our standards are very high, but there are some things that are qualitatively different about Cogent. If you're looking for someone to tell you what to do, in detail, then we're not the place for you. We're much more likely to give you some rather vague goal and ask you to figure out how to achieve it - and a lot of the things you need to do won't involve programming. They may involve marketing, or copy writing, or business analysis, or something as mundane as going and buying some stationery.

We truly need you to be collaborative and collegial - we don't have any places for people who want to work alone or who don't want to subject their programming thoughts to critique. Bob Sutton's "The No Asshole Rule" captures our philosophy quite well. In exchange we'll be completely transparent to you - you'll know our clients, our rates, our revenue, our costs, and everyone's salaries. You'll have the chance to be involved in decisions that you probably don't even know happen at your current employer.

We need you to be passionate. While we pay good salaries, we need you to be the sort of person who would program for enjoyment even if you weren't getting paid for it. We need you to be highly ethical - to be more concerned with doing the right thing than the profitable thing if there's a conflict.

We're interested in programmers, web developers, business analysts and possibly testers. So if you're interested in undertaking a variety of consulting work, off-site development, and product development at a place like Cogent, please drop us an email.

Runway

Cogent is very proud to announce the release of our very first product - Runway!

Runway is an action management system. It's inspired by Getting Things Done (GTD), and will eventually grow into a more complete GTD system. Why do you need an action management system? Because your brain is a terrible secretary?Right now you're wasting precious mental energy worrying about things you need to remember to do, which ones are important, which ones are urgent, what needs to be done next, and so on. Runway provides a trusted repository for all the things that you need to do - and trust me, there are hundreds of them.

Runway is designed to be quick and simple to use, and to become intuitive over time. An action is created through a simple, single-line entry field. No check boxes, no drop-down lists, no tabbing between fields. You can also create an action by sending an email to Runway, or by sending a Twitter message. We want to extend Runway to other sources, so that you have ubiquitous capture for your important ideas.

Actions appear in your to-do list right away, and can be prioritised easily with drag-and-drop. You can rapidly filter your actions by when they need to be done, the context you need to be able perform the action, the time required, the energy you need, and any other tags you want to use.




Most people will use Runway to track all their actions, select the actions for the day at the beginning of the day, and then work through that list. I've been using Runway that way for over six months.

I'm really excited by Runway, because it makes my life simpler and helps me get things done. It's also a great piece of software, but I hope that people forget about that, that Runway merges into the background and just becomes an invisible helper. Please visit http://www.runwayapp.com and give it a go. Perhaps you'll have the same experience as Jonathan, one of our beta testers, who says, "Runway has changed my life!"

Cogent is talking about open rates

Some of you will already know this, but Cogent is an ongoing social experiment along the lines of Thoughtworks, but with different axioms. Transparency is one of our axioms, but historically we've applied this internally and the public information about Cogent has been much the same as what you'd know publicly about any other consulting company. We're about to step that up a notch and publish our rates schedule publicly.

As usual, we see pros and cons to this decision. First thing is that no one else seems to do it, so perhaps we're just being stupidly naive and we'll discover the reasons why no one else does it in some catastrophic way.

More obvious to us that we lose one of our supply-and-demand levers. Our supply (our employees) is fixed in the short term, and it's always been hard for us to figure out what the "real" demand for our services is (we get plenty of unsolicited contacts that don't turn into any business). One of the levers we can use to affect demand is price - if we had lots of people doing non-billable work then we'd clearly think about dropping prices to get people onto billable work. Historically this would have been transparent to customers, unless they talked to one another, but with public pricing it will be clear if we offer discounts.

We may also find that we get less contacts because people look at our prices and decide that we're too expensive without even talking to us. It's not clear if that's good or bad - we may actually save time because we don't waste time doing estimates for work that's never going to proceed anyway. Or we may miss out on legitimate business.

And finally, our permanent colleagues on consulting gigs will now have a pretty good idea of what the consultant sitting next to them is being charged out at. That may or may not prove embarrassing (hoprefully not).

So why do it? We have some feedback that clients like simple, public rates schedules. It means less discussion internally about "how much as we going to charge this client?". And it means extending the reach of our core principles, and each time we've done that in the past it's been good - if nothing else it tells the employees that we "walk the walk" consistently.

We've split the rates along two dimensions - the type of work and where the work happens. We do two types of work - agile coaching from senior staff, which involves some hands-on development but is focussed on influencing the entire team rather than producing features directly, and development work, which is mostly focussed on delivering features but also on influencing the entire team to work more effectively. We have different rates for agile coaching and development work, and we also charge less for development work that's performed at our own premises. There are three reasons for charging less for working on our own premises - i) we aren't able to influence the client staff as well, so we deliver less value; ii) we prefer working on our own premises and price our services to encourage this; iii) when we're working on our own premises we're effectively competing against teams all over the world and we need to reduce prices accordingly.

So here are our rates for new work in 2009, all exclusive of GST:

Agile Coaching

• Senior Agile Coach: $1400


• Iteration Manager: $1300

Development (consulting / offsite)

• Tech Lead/Architect: $1200 / $1000


• Senior Developer: $1100 / $ 900


• Developer: $1000 / $ 800


We're interested in what people think of this approach to pricing, so please let us know.

Design Improvement bids close this Friday

A reminder for anyone considering the Design Improvement workshop that bids close this Friday. We've got 12 distinct bidders at the moment, so if you're interested you should probably make a bid near your final limit rather than trying to be tactical about it.

Also a little advance warning - we're looking at running an EAT Design Patterns workshop in May, so watch out for that or let me know if you're interested in getting mail when it's announced.

Presentation at Melbourne Patterns Group

I'll be doing a presentation on the Visitor pattern at the Melbourne Patterns Group on Wednesday. I've attached the announcement below (cutting out the bit that said what I was talking about - oops!).

---

The next patterns group meeting will happen on March 7th at the usual time and location: 6:30 pm at ThoughtWorks Office, Level 11, 155 Queen Street, Melbourne 3001. Parking should be
available near the building.

Please let me know if your coming for the meeting so that I can arrange for the pizza. You can rsvp by forwarding this email to sreeni@gmail.com. Since the building entrance is locked from 5:30 pm, myself or a fellow ThoughtWorker will be patrolling the entrance between 6:30 and 6:45 to let people in. Please call me at 04 3396 3725 if you are left waiting.

Design Improvement Workshop

We just took our tenth bid for the Design Improvement Workshop on March 24. We'll continue taking bids until midnight March 17, moving up in $50 increments. Remember that ties are won by the person who bid first at that price, so it's an advantage to bid early!

I'm really looking forward to seeing everyone on the day - I think this will be a great workshop.

Update - One subtle point is that increasing your bid doesn't necessarily increase what you pay - the final price doesn't change until everyone increases their bid.

Design Improvement Workshop

The January EAT workshop was a great success, so we've decided to do it again. I'm pleased to announce that Marty Andrews will be presenting our Design Improvement workshop on March 24. As with our previous workshop, we're limited to 10 places and pricing will be determined using an auction process. You can see the latest bids and access the workshop details on our
wiki.

First EAT workshop

We ran the first EAT workshop on Saturday, and it went very well. The setup at the venue wasn't perfect, but we think we have a way to set it up better next time. I like an environment with plenty of light, but if anything we had too much yesterday (at least for projection) so we'll try setting up in the ante room, which has blackout curtains, next time.
And the feedback from the participants was very good. Thanks very much to Marty for co-teaching and for providing the data projector, and to Nigel for coming along and adding his expertise. I'm getting used to working on my MacBook, so I'll gradually get better as well. Alec Clews, one of our attendees, has posted his comments.

 

 

Although the examples and discussion for this workshop were in Java, we're now able to offer the workshop in .NET as well. We're unlikely to run the TDD workshop again for a while, but we'll probably run a design improvement workshop in March - contact us if you'd be interested in that.

Testing images

This is a photo I took while travelling in the US.

I hope it posts ok, but no luck so far.

Test Driven Development workshop notes

I've just finished porting my TDD workshop notes to S5, adding all the code examples, and in general buffing them up for the EAT workshop on Saturday. As usual, I feel that the value of the workshop comes from the dialogue and the interaction, not just from the slides, so I'm happy to make those publicly available, provided you leave the accreditation in place. I'm very interested in any feedback you might have - for example, I've just realised I need to add some Creative Commons licensing to the material, but I'm sure you'll have other things to say!

EAT update

With just over a week to run, we've got 10 bids for the Test Driven Development workshop, which is great - this means that bidding will close on midnight Friday. If there's sufficient demand in the next few days I'll look at running this workshop again in February.

EAT details

BarCamp Melbourne

I've read about BarCamp, especially in the blogs of Kathy Sierra and Tara Hunt, so it's good to see that there will be a BarCamp Melbourne in a few months. I hope to be able to attend but I'm not sure about that at the moment, which is why I'm not on the attendee list.

Marty Andrews co-teaching TDD course

I'm pleased to announce that Marty Andrews/ will be teaching the EAT TDD course with me on January 20. Marty has a wealth of experience in agile development, particularly TDD, and it will be valuable for people to get both our perspectives.

Welcome!

After a few weeks of working with CSS and templates, and then trying to figure out why I wasn't getting email delivered (still not quite resolved, but working in at least some cases), I'm happy enough with the blog configuration to start posting. Nothing serious, but at least it's not empty now. There will be more in the next few days and weeks.

Welcome!

After a few weeks of working with CSS and templates, and then trying to figure out why I wasn't getting email delivered (still not quite resolved, but working in at least some cases), I'm happy enough with the blog configuration to start posting. Nothing serious, but at least it's not empty now. There will be more in the next few days and weeks.