JAW Speak

Jonathan Andrew Wolter

Archive for the ‘thoughtworks’ Category

Being Part of ThoughtWorks: Pillar 3 Social and Economic Justice

with 4 comments

Reading time: 2 – 3 minutes

At ThoughtWorks, we have many great technological projects, and brilliant coworkers. But beyond all that is a power for social good that is out at work in the world. Today, many of us are involved in ongoing projects with UNICEF and other non-profit organizations, helping solve fundamental human issues with technology. Last winter North America had an all-hands, and we brought in people like Merrick who’s helping the world with mobile SMS based apps at UNICEF. And we have Jeff Wishnie who is a Silicon Valley veteran, paragliding instructor, and now our Director of Social Engagement. He brings both socially aligned clients, and goes out and leads missions into all parts of the world using technology to better humanity.

ThoughtWorks has three distinct pillars that describe it:

  • First it needs to be a sustainable business.
  • Second it champions software excellence.
  • Third it has a passion for social and economic justice.

Our founder and chairman, Roy Singam, sent a great email out a few days ago that inspired this post, and reminded me the importance of how each of us choose to spend our working hours. Over coffee and engaging life-beyond-mere-profitability conversations he gave me permission to quote him:

“Being part of an organization that advances a cause is an important. Associating with people who collectively encourage moral behavior is one of the most important decisions one makes in life. To ignore this and treat these decisions as simple career decisions (or give a little guilt money) is avoiding moral responsibility.”

We have ThoughtWorkers on the ground in real projects working with global and local NGO’s that allow us to directly apply technology, process design, and lean management to changing the world. The mobile space is especially exciting.

I believe future proof, profitable corporations, with reason beyond profit will retain the most capable employees, and provide lasting global impact as 100-year socially-positive companies. Profit, smarts, and growth is essential, but the meaning of work-life must extend beyond the bottom line.

Written by Jonathan

April 29th, 2010 at 1:48 am

Posted in career, thoughtworks

Future of Work at London Business School: My Take on ThoughtWorks Globally

with one comment

Reading time: 2 – 4 minutes

Thanks to Roy’s urging, over the last 6 months I’ve been involved with London Business School’s Lynda Gratton in a consortium on the Future of Work. What will work look like in 2020, and how can companies become “future proof?” Specifically, what will global corporations look like? We kicked it off in London last November, where we met and discussed with people at several dozen companies. It’s been an honor, and a time to meet many interesting people.

Today, looking back at it, I am extraordinarily proud to call myself a ThoughtWorker. As an employer, we have a unique positioning of a global culture, lived out social values, and world changing technology.

Go visit any ThoughtWorks’ office in the world and you’ll find many people on international assignment. Further globalization and virtual-globalization will permeate work in 2020 — but today we clearly stand out as a leader amongst our peers. On vacation last winter in Beijing (pictures), I visited our office. It felt no more like I was in China then if I were in our offices in Bangalore, San Francisco, London or Chicago. It was not an “American culture,” but a “smart, interesting, passionate” culture of people with deep and varied interests — surrounded by great technology and delivering some game-changing products.

We encourage frequent cross-pollination of ideas and experiences through short and long term transfers. I felt right at home, met some amazing people (fellow TW’er and father of the Chinese internet Michael Robinson), got set up with daily Chinese lessons, and returned to visit in the office (for said lessons) almost every day.

There are so many more things to write about. It’s inevitable for work in 2020 to involve more cultures, countries, and languages. The marketplace for your goods could be half way around the world. Virtual-workers and virtual-meetings will explode. Yet, I also predict more face time with global coworkers. (Think how the world will change when we have US to Asia, or Europe to South America point to point travel in a few hours via spaceflight.) This will usher in increased complexity, and security measures; however I am excited for the future.

I have many more ideas, especially about the social values side of work in 2020 — but in true agile fashion, I’d like to see if anyone is interested in this before putting in more time up front.

Written by Jonathan

April 9th, 2010 at 7:41 pm

Posted in career, thoughtworks

Linking to Miško’s, Russ’ and my Testability Guide

with 3 comments

Reading time: 4 – 6 minutes

I had the great pleasure of collaborating with Miško Hevery and Russ Rufer in creating the Guide for Writing Testable Code. Please feel free to check it out, and leave comments here or on his blog.

Here’s a peek at the different flaws to watch out for, and warn your co-workers about. If you see this in code that is getting checked in, bring it to the attention to your team. See Miško’s post for the full list.

Flaw #1: Constructor does Real Work (link)

  • If you have a constructor that is doing “work” you’ve established a contract that everyone who wants to create this object also is forced to wait for that “work” to happen. This becomes a huge problem in small unit tests. Frequently unit tests create many, many instances of the object under test – and any work you do in the constructor slows down tests.
  • The solution? Break up the responsibility into two objects: a builder of factory to do all the heavy lifting to construct the object, and whatever the original object was that had the heavy constructor. When you split the responsibilities up you will have a better object oriented design, and make it easy for more flexible construction. If you’re tempted to create an init() method and put the work in there – avoid this siren song. It’s a smell of mixed responsibilities and a poorly behaving object that isn’t really ready when the constructor completes.
  • Warning signs are:
    • new keyword in a constructor or at field declaration
    • Static method calls in a constructor or at field declaration
    • Anything more than field assignment in constructors
    • Object not fully initialized after the constructor finishes (watch out for initialize methods)
    • Control flow (conditional or looping logic) in a constructor
    • Code does complex object graph construction inside a constructor rather than using a factory or builder
    • Adding or using an initialization block

Flaw #2: Digging into Collaborators (link)

  • Jumping from one object to another to another to get what you want makes for hard to test and hard to refactor code. This is commonly viewed as the Law of Demeter violation, however you can dig into collaborators without breaking the letter of the law. This is hard to work with in tests, because your tests need to do a great deal of setup stuffing objects in objects into other objects, or else you’ll get null pointers.
  • Warning signs are:
    • Objects are passed in but never used directly (only used to get access to other objects)
    • Law of Demeter violation: method call chain walks an object graph with more than one dot (.)
    • Suspicious names: context, environment, principal, container, or manager

Flaw #3: Brittle Global State & Singletons (link)

  • Global state (usually made possible through the static keyword in Java) creates hard to test and modify code. Parallelizing tests is often impossible, and tests that forget to clean up the global state after running interact undesirably with other tests (causing unexpected failures).
  • Warning signs are:
    • Adding or using singletons
    • Adding or using static fields or static methods
    • Adding or using static initialization blocks
    • Adding or using registries
    • Adding or using service locators

Flaw #4: Class Does Too Much (link)

  • Object oriented design allows you to split responsibilities into individually tested objects. Using an object oriented language does not prevent people from writing procedural code. In fact, most times when someone does not want to write tests it is because their code is hard to test.
  • Warning Signs:
    • Summing up what the class does includes the word “and”
    • Class would be challenging for new team members to read and quickly “get it”
    • Class has fields that are only used in some methods
    • Class has static methods that only operate on parameters

There’s typically no magic wand to wave and make hard to test code instantly testable. Engineers need to have an open mind and learn how to write code designed for testability. (In my experience 90% of the time this involves test driven design and test driven development.) These ideas above, and many of Miško’s other posts are a fantastic starting point for adopting that new way of thinking.

Please link it up with your favorite testability mindset readings.

Written by Jonathan

November 29th, 2008 at 5:26 pm

Chicago to San Francisco, by way of India

without comments

Reading time: 2 – 2 minutes

I’ve really, really missed the really smart people I used to work with.

I believe working full time, with great people, and doing my own projects on the side will be vastly more productive than having full time for my own projects.

After leaving FeedBurner with the Google acquisition, I gave myself 2 months of running my own business full time. After that period, I would either be hiring folks, giving myself a few more months, or getting more experience at a startup or consulting.

Second Valley’s revenues are up a healthy 25-40% compared to May. I’ve been spending time in Ruby on Rails, and have started rebuilding the full ecommerce and delivery platform for one of Second Valley’s sites. But I missed the smart coworkers.

My decision Wednesday was to email ThoughtWorks and continue my interview process I started prior to joining FeedBurner. Well, thanks to the amazing Carrie McComb, I interviewed Thursday and had an informal offer that night. Friday morning I signed and it’s official.


In 10 days I’ll be off to India for ThoughtWorks Immersion training, and then I’m relocating to San Francisco.

Photo credits: meaux, and artview (my previous trip to India)

Written by Jonathan

August 10th, 2007 at 3:04 am