Last Day as ThoughtWorker

Last day as ThoughtWorker, writing this blog that I have been putting off until the last minute, I find myself lost in thoughts in all the things that I have experienced since I joined ThoughtWorks 30 months ago.

It has been a nothing short of life-changing experience. As a matter of fact, it is with these changes that I have decided that in order for me to push even further, I will have to go out and look for good opportunities that can help me, rather than waiting for them to happen. As I going through the projects, my expectation on what I can do on the project has changed dramatically.

When I first joined, I was just happy if I can merrily write my tests, be happy about the 40-hour week and that the CEO is not trying to cash in one million dollars every quarter when the company stock is not going anywhere (like some company that I have worked for). Now on my last day, I have found myself comfortable coaching agile software development and influencing project management. I have experienced all the things a senior developer can do in a project, and even have had a short taste of being an IM and PM. I have been to China, twice, to lead projects. I have been on more and more discussion and presentations that involve more than "TDD" or "patterns". I am even pulling an effort with several others right now to write a book that we hope can be published.

Like my fellow Borlanders showing me the way to be a good developer, my fellow ThoughtWorkers have helped me understand what it takes to have a success project, besides technical execellence. I created this blog for my experience in ThoughtWorks. I have grown fond of it over the time and I am going to keep it up for my experience in applying agile practices.

So to wrap it up:

First several books that I read as a ThoughtWorker:

• Enterprise Application Architecture
• Domain Driven Design
• pragmatic Project Automation

Most recent books that I read as a ThoughtWorker:

• Tipping Point
• Blink
• Build to Last
  
• Blue Ocean Strategy
• Crystal Clear

Things I enjoyed doing in ThoughtWorks:

• Talk to Roy (don't worry about subjects)
• Meet old timers, they will show you why the idea that "employee managed company" has a chance in ThoughtWorks. (If someone was surprised that you were not one, it is a compliment)
• Meet at least one ThoughtWorker from each office from other country, especially the noisy ones.
• Request traveling to other country for a project.
  

Things that would be fun to do in ThoughtWorks:

• Tell Obie that ruby won't fly because it does not have an IDE like IntelliJ and it is not type safe. (well, maybe not anymore since he has been fighting that battle for a while and getting very good at it)
• Tell Hammant that you love Spring
• Buy beer around the table and ask for airplane takeoff and landing stories

Things that I did not enjoy doing:

• On beach for more than two weeks
• Travel weekly with connection flights each way.
• Stuck in an airport for a delayed flight for 7 hours
• Stuck in an airplane on the ground for 3 hours
• Saying goodbyes
• On your last day, be notified that you won't be covered by medical insurance anymore (So much for chilling out before the next job), even though you have accumulated over four weeks of vacation, and you could technically take your vacation before you send in the two weeks' notice, getting covered and accumulate additional vacation at the same time. The reason? You are not worth risking the liability anymore, now that you are not going to make money for the company and all. (Not in that word but I get the message)
  

I would have put boring period of the project in there but the following are what I have done each time I got bored:

• Learned Dvorak
• Created open source projects: http://www.shaneduan.com/opensource.html
• Read books
  

Tricky Business of Being a ThoughtWorks Consultant

I have been thinking about this for quite a while and the topic came up again recently. So I figure I might as well write it down. Keep in mind that these are my personal opinion as ONE ThoughtWorker based on my situations.

Blog or not to blog

Historically, my blog thoughts come through several ways, all of which is under the condition that requires me to blog at airport or late at night (like now).

1. Feeling Pain

As the book "Project Retrospective" has pointed out, when you feel the pain of doing something, it is very important to stop for long enough period of time to reflect about what you are doing. As true as it is, which makes me a true believer of retrospective, I still have the same amount, if not more than usual, of billable work that I need to do. When I do come up with an idea of improving the process, I only create more work for me to talk with others to sell the idea, one more thing on my coaching list, and a task to implement the fix.

So at the same time that I have learned a new aspect on software development, I am also burned out more from my day's work, which makes it a lot less appealing to write a blog about it. Sometimes an idea has to go through several round to mature, so I hold off the blog. Then when it is mature, I have got used to it and don't feel the excitement and urge writing it down anymore.

Yes probably it would be ideal if I can slow down my other work so that I can keep my energy up everyday, which brings back to the title "consultant", as in, like it or not, I am being paid to live up to my previous promises as much as possible.

2. Learning something new

When I got to know about something new, I always find a way to apply it so that I can learn more. What that means is my afterhour will pretty much be occupied by those activities rather than blog about my incomplete thoughts about it. To name a few:

Behaviour-driven development: Liz from UK office did a presentation on jBehave in the China office. After that, I start visiting Behaviour-driven website to learn more about it. When we created Cotta project, we decided to give it a try and it turned out to be very well. But the IDE integration sucked very much and jBehave is a bit rough around the edges (like loading all behaviors), so we joined jBehave project, created Eclipse and IntelliJ plugin and fine-tuned the API, during which process the site building part of BuildMaster became mature.

Can you imagine me keep a log of all these activities while I am working on them in my afterhour? I didn't think so. Although now I realize that I have different take on BDD from Dan North and Dave Astels, maybe I should write something about it, well, after I finish this thing about build and release that I learned from last project, and my thoughts on how BuildMaster can rock the world.

3. Getting Into Interesting Internal Discussion

From time to time I met people, ThoughtWorkers or not, who are not afraid of expressing their opinion and discuss about it. A lot of the time the outcome of the discussion is that "We now know what we don't know" (in a good way, kind of like your feeling after finish reading "the World is Flat" from what I have been told). So is there a point of blogging that? Maybe, maybe not. How to blog it, what is a good balance to strike, I think this is the time when I feel that technical writers are being paid for a reason.

Discuss or Not to Discuss

A good project is a project that is under "Total Quality Control", i.e., every single detail of the process is constantly under review to see if there are any room for improvement. Since ThoughtWorks has got itself out of the staffing business, ThoughtWorkers are generally taking the lead on the projects.

Whenever a new ThoughtWorker joins the project, it is more than welcome, as part of ThoughtWorks culture, for him or her to question every detail of how this project is run. Sometimes debates will rise during the day so that everyone can understand not only the way it is but also the history behind it.

On the other hand, ThoughtWorks is brought in as "consulting firm", being paid to say what the right way is to run a process. So when the new member joins and debates start occurring, it can be potentially perceived by the client as the incompetence of the existing project lead, incompetence of the new member, mismatch of the personality between the parties, or weird management style of ThoughtWorks.

This happened to me several times, and luckily, my clients have been open enough to raise the question thus giving me a chance to explain. It happens a lot less now because the first impression that I am trying to make is that "there is generally no silver bullet". At the same time I am giving out suggestions, sometimes strong ones, I also tell the reason behind it and that those reasons are revalidated constantly.

Then that makes me look like the kind of consultants that I have had contact in the past, with who are all talks and never tells the client anything concrete, the exact kind that I loath and want to stay way from.

Hence the "Tricky Business".

There are a few more thoughts on this but they are not as well thought. Plus it is 12:30am now and I did plan on have a full night sleep for a change, well, after I finish ironing my shirt for tomorrow.

One Week in SLC

The past four days just flew by and I am now sitting at the airport waiting for my flight back. I was hoping to fly my wife over so that we can visit the mountains around here during the weekend but it turned out to be much more expensive. That is OK, I still need to scout out the beach park where I am going to host the BBQ party next weekend.

I held on to a story card and paired with different developer each day. The domain that this story affects turned out to be the worst part of the application so each day I did a bit of clean-up and refactoring. The story dragged on a bit but I managed to make steady progress.

Since this is a .NET project, there are SQL server and IIS server to run on the laptop. After figuring out how to start and stop the service from the command, I wrote two Ruby driver class for them in the hotel room and checked them into BuildMaster.

So now I have a script that I can call to stop both service with:

services.rb stop

and all it does is:

services = [
BuildMaster::IisDriver.new, BuildMaster::SqlServerDriver.new
].each do |service|
service.send ARGV[0]
end

Back on the Road

After almost three months of local project, which I intend to log sometime soon, I am back on the road again.

This time I have my Verizon national access card that allows me get connected to do things like writing this blog at the Oakland airport. I could request the extra battery but with only 3-hour travel time I doubt the weight is worth the benefit.

Next project is an ASP.NET application and have quite a few ThoughtWorkers on it. I am afraid that is as much as I am allowed to say. I would like to whine about the painful download/install process I have been through in order to run the application, but I don't think anyone, like .NET or not, would care.

This project is on a 4-10 schedule which means once I get myself comfortable with the code and my role, I will be able to spend only 3 nights in the hotel and sleep at home 4 nights per week. Not that I am tired of traveling but there is something to "sleeping in your own bed".

ThoughtBlog

Adewale Oshineye sent me an email because there was a link from my profile page on ThoughtWorks linking to this blog, to ask me if I want to add mine to the ThoughtBlog. The reason that I have not done it is because I want to start publishing this blog only when I really know what kind of blog I am going to keep here, or even if I think it is worth it to keep a blog about my experience in ThoughtWorks.

But I figure, help is already here it really does not make sense to turn it down so I replied yes. Then I figure it is time to subscribe to the blog feed to see what my fellow ThoughtWorkers are writing about, especially with ThunderBird it is so easy.

So already I have learned something new today! I thought I have known all that is to know about writing assertions (assertEquals, assertNotEquals, assertTrue, assertFalse, simple, eh?). Boy was I wrong. Joe's blog "Flexible JUnit assertions with assertThat()" sure opened up my eye.

When I was working for JBuilder, I wrote a test framework for unit-testing some part of JBuilder modules. When a test fail, it is always desirable to see as much information as possible in the error message regarding information like project configuration, run configuration, etc. However, JUnit requires you to provide a message before the assertion happens, which means that all the tests will need to spend a lot of time constructing the messages, even though they might not be needed. So I wrote this LazyAssert that only constructs the message if the assertion fails, and ended up duplicating a lot of Assert APIs. I was quite bugged by that result but concluded that there was nothing I can do.

And now I know the right way.

My hats off to Joe for sharing it with us. And again to my fellow ThoughtWorkers.

Update of an example:

Check this out:

before:

junit.framework.AssertionFailedError
...(Click for full stack trace)...
at com.company.product.person.dao.jdbc.JDBCAffiliationDAOTest.testInsertAffiliation(JDBCAffiliationDAOTest.java:92)
...
at org.jmock.core.VerifyingTestCase.runBare(Unknown Source)
...

after:

junit.framework.AssertionFailedError:
Expected: timestamp is after 2005-05-16 15:21:34.871
but got : Mon May 16 15:21:34 PDT 2005

...(Click for full stack trace)...
at com.company.product.test.BaseAsserts.assertThat(BaseAsserts.java:31)
at com.company.product.test.BaseAsserts.assertThat(BaseAsserts.java:23)
at com.company.product.person.dao.jdbc.JDBCAffiliationDAOTest.testInsertAffiliation(JDBCAffiliationDAOTest.java:93)
...
at org.jmock.core.VerifyingTestCase.runBare(Unknown Source)
...

Fellow ThoughtWorkers

One thing that I found different working at ThoughtWorks, are the fellow ThoughtWorkrs. Here are three examples:

Names
I am the kind of person that cannot remember people's name unless I get to know them personally. So even though I greatly enjoyed the book Patterns of Enterprise Application Architecture, I only know the name of the main author Martin Fowler. Well, after working at Yabe project, I picked it up one day again to look up a pattern. Guess how surprised for me to find out that of the people that I worked with, three are on the cover (David Rice, Edward Hieatt, Robert Mee). Even though only Dave works for ThoughtWorks, I think this still shows that this company is well connected.

Arguments
ThoughtWorkers are all opinionated and love a good argument. Someone told me this the first week that I joined, and I have seen it again and again. I think this is good because it will bring out the best from all sides so that we can always think of the way we look at things or do things. Of course, I can understand that it is not for everybody, even though I enjoyed every argument.

Humorous
Here is a good example. During a discussion about the practical use of loosely coupled architecture like web services, EJB, or CORBA, Dan North made the following comment that cracked me up:

You mean you don't use CORBA?? Are you mad??

How on earth do you instantiate an object without first looking up a Factory Factory using IIOP to register as a Listener for a Factory to call a Factory Method via reflection, if you don't have CORBA?

Bloody amateurs.

Happy Apile Fool's Day

On this day, there are two things that I want to mention. Normally I stick this blog to my working experience, but I figure everything has an exception...

GMail bumped up everyone's storage! This is one company that keeps reminding me that you can make things better by making things right. They keep on surprising me in a good way and I just love this company more and more. As a matter of fact, I would have worked for them, if their HR were not so slow on setting up interviews (that was an interesting experience last year, switching my Google HR contact three times in two months), that I ended up running into ThoughtWorks, a company that I should have been working for since year 2000. Even though my job in JBuilder was a great experience, I am sure I can do much better in a company like ThoughtWorks.

ThoughtWorks name was mentioned in a April Fool's webpage (PaiOn Chair). I asked around and didn't hear anyone knows the folks in Cenqua. So if that is the fact, this is a good sign that we are being regarded as THE XP shop, a name that everyone is building for.

Office Friday

I did not realize the importance of office Friday until we did it last week. Last time we did it, I was working in the office so it was no much different for me, well, plus that I was crunching on the deadline to fix something so I did not find enough time just hang around in the afternoon.

This time I worked extra hours on Thursday and went to work early on Friday, so that I can take the afternoon off and went back to the office. Meeting other people in the office that have been on the road was surely fun. And it was defenitely good to chat with Dave and Scott again. I think enablement work does wear you out slowly because you have to keep teaching other people. Besides patience and money you don't really gain much. I guess one can also learn how to deal with badly designed code and old code but it defenitely is not as pleasure as working with another person who is familiar with XP and have a stimulating conversation. I am not saying the people at Drofnats are dull, it is just that repeating and explain the things that I have taken for grantetd for the last three years is really not all that exciting (seeing the delight in the deveopers' eyes was rewarding, though).

New Project : Drofnats

Started the next project in, let's call it, Drofnats. Compared to the SFD that I visited two weeks ago, this one is just the oppsite. The IT department, at least that ones that we have been talking to, are very much open-minded, after being bitten by a bad project management.

It is quite interesting that according to the switches of scope, time, cost and quality, they are very willing to achieve high qualty, less likely to cut scope, and flexible on time and cost. I am really very happy that they picked us than the other two companies, one of which is IBM, because they could be used if not careful. It is such a good candidate for Agile development, and I really hope we can have a great success.

Today is mostly spent on preparations. The pilot inception deck power point is the most interesting. It reminds me of the design document that we had at Cysive. It is very powerful but yet not to be abused. However, I especially like the slide of "Is and Is-not". It clearly specifiies what is to be covered and what is not, in a simple two-column table. This means that it did not take too long to produce, it will be easy to change, and yet it clearly defines the scope so that everyone will be on the same page.

It is also my first agile project from beginning. In Yabe, they have already planned it by the time I came in, and it was not by a ThoughtWorker. Even though this is not from the very beginning, I still get to see the iteration zero, or the equivalence. It is hectic at certain angle, but it is being handled very well.

The project estimate chart is the next thing I should check out. I also like espeically the way priority/rick/scope is being presented by a two dimensional chart with dots whose size match the scope.

Finished Two Projects

Just finished two projects of a client, let's call this client Yabe for potential legal issue.

Yabe is a big client, brought to us by friend of ThoughtWorks. They use ClearCase and Eclipse. I have to say, the set up of the ClearCase and Eclipse is very anti-agile. (I'd like to say it is the products themselves but I have met some other developers that argued that it is the setup instead of the tools themsevles). Everytime I work on this environment, time just fly by while I am staring at the screen waiting for something stupidly long to finish, and before I know it, it is already past 9pm. I cannot imagin how in-hourse developers live their lives, but I sure hope their stock options are well worth it.

(Ok. Here is a good example of how screwed up these tools, or their settings, are. I renamed a private static method that takes no argument and returns void, and it tooke Eclipse 2 minutes to come back. Auuuuuuuuugggggggggggggggggggggggggghhhhhhhhhhhhh)

Here is another testimony of ThoughtWorkers' ability. Dave and Alex (An independent consultant) pulled the subsystem and its library over to a CVS repository, and use IntelliJ to build upon it. CruiseControl is set up. Periodically we sync. up to the Yabe world using a script that Alex wrote. So with CVS and IntelliJ, we were able to happily write programs using test-driven development. Yabe has a document that supposely contains all the requirement of the new application, similar to the use case document. We divided it up into story cards, gave them numbers and came up with our estimates.

So from our team's point of view, we are doing pure XP. We pair, we track, we test, we refactor. The resulting application stays healthy wihle we continue adding more and more compilcated features (BTW, writing web application without using session tracking is not a trivial task). It is my first XP project since the one for Novell in year 2001. And it just felt like an place I belong.

One problem is that as far as the customer concerns, this is just like any other project that they have done. Throwing the document into a blackbox and hoping something good will come out of it by the time of the contract. We didn't realize that ANYTHING different from the document, we were supposed to get approval from the customer. Of course being an XP team, we simply shot an email to the client project manager, asked the question and did the change. At the end, we did more than what the document said, and yet the customer thought we were two-week behind.

Let's Get Started

Ok.

After four months settling in, I finally start writing my blogs.

The reason for this blog is because I have a good vibe about this new company that I recently joined: ThoughtWorks.

There are three main reasons that made me want to leave my rewarding JBuilder career and start a career that requires traveling, talking, dealing with new environment all the time.

1. Extreme Programming and Agile Development: I believe this is the future of the software development. Or at least this will be a very good alternative of RUP. However, I also see frustration during adaptation of XP methodology, to a point that I almost think this is a ideal goal that can never be achieved. However, ThoughtWorkers seem to have done it very well and are up to the challenge of making it into a medium to large size team. If this methodology can be applied to a bigger size project, I defenitely want to be part of it.
2. Career growth: Again and again, Borland management has disappointed me making me realize that there is nothing left for me in Borland. I could talk about the reason for a whole day but I am really tired of it and I'll save my breath here. ThoughtWorks honor developers very much and even though time still has to tell how much I can grow my career here, I feel much more confident in working here. I could learn the art of project management of agile development, and understand what it takes to deliver a good project. There are OpenSource projects launched by ThoughtWorks that I can get involved into. China is also a very good market for software development.
3. Martin Fowler. I have read most of his books and have been up to date on his websites. I believe if he chose ThoughtWorks out of all the possible companies, it must has done something right for him.