Years and lessons working at ThoughtWorks
thekua.com
thekua.com
The ones I like best here are:
#5 Architects make the best decisions when they code. Amen.
#10 Appreciate that everyone has different strengths - that's how a team becomes more than its parts.
Here are my lessons learned from 25 years of SW development: http://henrikwarne.com/2015/04/16/lessons-learned-in-softwar...
YAGNI FTW!
I spend the vast majority of my time on "architecture" (as opposed to coding) making it so that it's trivial to track down problems in production, trivial to identify the cause once you do, and trivial to deploy the solution once you've made the fix.
If you do architecture right, most fixes end up being the moral (if not literal) equivalent of one-liners. At least, that's been my experience.
Do architecture wrong (or worse: not at all) and you end up having to rewrite and/or redesign your code entirely, just to identify and/or fix bugs (i.e. not even adding new features).
However, like you, I find that I'm often pulled away, and if I invest the time time make what I'm doing of a high quality (walk the talk), I'm typically neglecting higher value tasks.
The biggest challenge I have is managers who know you get on the tools, who turn around at crunch time and expect you to dive in and fix issues. Sorry but whilst I am indeed an expert troubleshooter, because I know the architecture, and designed to minimise a lot of these issues, I'm not usually the best person to foresee the impact of my fixes, and again, due to wanting to set a solid example, I don't want to do a hack to fix it, so it takes a quite a long time... when I should be triaging, providing troubleshooting insight, and considering any architectural changes that make whole classes of problems less impacting.
It's not just a matter of coding, it's about the right kind of coding.
I like to have architects be pareto-programmers, that is they get to 80% of of the solution so that they can hand off the rest to a less-experienced team member. They can solve the hard part of the problem without getting stuck making it productionized and provide an opportunity for mentoring.
There's two other code related tasks that are important: code reviews and commit reviews. They give views at different "heights". We have fairly good tooling around the former; I'd love a tool that gave me an email every morning that had X number of random commits distributed over the total committers as best as possible while showing me who hasn't committed for a while.
The worst is when they say "This is your code man. I'm just helping you out a bit."
No. Finish the fucking feature so I can focus on my fucking feature without having to tripple check all your damn work.
And I'm a guy with 15 years experience, 10 years frontend.
Hence much frustration often.
If an obviously junior developer is given an obviously 'fun, interesting' task, they should pair with a developer or have frequent reviews so any problems are caught before pull request stage. You need to catch these sorts of things before you get so late in the stage.
Additionally, you need a structure and culture that is able to hold back pull requests if the code is bad - that's the whole point of code review!
I mean, anyone senior around here should know that it's precisely making something production ready, as opposed to just 'work in theory', is one of the hardest parts of software: Who hasn't seen some code that mostly works, but is operationally unusable? Something that works with 1 server, but when you put it in 20, it all blows up? It's not about the nice presentation, or the talk where you explain how you turned MongoDB into a queue, but about making a system that works almost all the time, but when it doesn't, it is not the end of the world, and easily fixable.
The sad part is, the world is so full of powerpoint architects and projects that don't provide any real value that many people have never seen a system work right. And that's why we see tons of SV companies that are built around tire fires: Nobody in charge of anything has ever seen a system that we shouldn't be embarrassed of.
This is exactly where senior architects make all their money.
Unfortunately, to work, the team under the architect needs to want these hand-outs. I'd wager that a lot of developers do not want to be simply told what to do or to clean-up and make it production ready.
In the end, I think a pareto-programmer architect selects for a team that simply does what it's told and that leads to a situation where no one will question the architect and that leads to bad code.
Behind the name Architects, you get lots of different understandings depending on the organization.
I have seen in being used as technical architects, business architects, solution architect, application architects. Usually only technical architects tend to mean some kind of coding, with the other ones being synonyms for some sort of manager.
So I always feel I need to describe what I understand for architecture role, to make sure everyone is on the same page.
An age old rule for managers. You can't manage or treat everyone the same. Certain people respond to certain things. That's why great managers are able to really pull the best work out of their employees. They know what drives each one of them.
ThoughtWorks needs to read this and particularly heed point #9. The primary goal of theirs during our month—or so—long consultation seemed to be to force a team of 40+ developers down a rigid and dogmatic path of TDD. They also advocated pair programming, but a lot of us (I'm extrapolating "a lot" from the unanimity of the few I was close to and talked to about this) felt like they were really just winging it; like they were apprentice developers barely learning the concepts of TDD and pair programming at the same time they were charging to purportedly teach us.
It was a frustrating and fruitless endeavor that taught our team basically one thing; don't work with ThoughtWorks again.
I'm sorry you had a bad experience in your brief engagement with TW. I believe it to be atypical, and I hope you'll have occasion to reconsider your -- not un-dogmatic -- conclusion.
As for your experiences with ThoughtWorkers, do bear in mind that at the end of the day, everyone is a human who could make mistakes. It appears from your experience note that the month-long engagement could have been structured better.
Pat is certainly very sharp and thinks deeply about issues. So are many other ThoughtWorkers, he is not alone.
But otoh, TW also has a minority of dogmatic agile/TDD etc people for whom such practices are close to religion and any other approach is blasphemy. It seems you might have run across some of them.
The best way for a client to use ThoughtWorks is to get their team to work on a chunk of software, keep them from switching taleted developers out for more junior folks, and add a couple of client devs to that team for a few months at a time. This ensures high quality and osmosis of practices without the kind of high pressure conversion tactics you seem to have experienced.
ThoughtWorks is a great company and has many talented and thoughtful devs, but if you are paying them you have to pay attention to how they work and not let a few bad apples run amok and destroy your team morale.
Just my 2 cents.
If you're interested in working with ThoughtWorks, I'm happy to help and connect you with the right contacts. Email joelparkerhenderson@thoughtworks.com.
I would recommend talking to the recruiter and let them know your preferences before declining.
Interesting, thanks. At my current job they try to staff local as much as possible, there is no formal hierarchy and we also have 20% time, so my standards are high. Traveling too much would be a no go for me.
Generally speaking, the travel is because the client wants the team to be on site and pairing with the client's people.
We have a bunch of people who prefer not to travel as much, and that's fine too.
Also, work-from-anywhere tooling is getting better and better, and more of our clients are asking about it. In my opinion these tools are really good though not as good (yet) as being in person in groups.
ThoughtWorks has developed Mingle - a project management tool, Go - a continuous delivery tool, Snap - a continuous delivery tool on cloud, Gauge - test automation tool. But you can also hire ThoughtWorks for consulting on agile organization transformation, programming practices, etc. If you are looking for teams to help you develop custom software with these practices, ThoughtWorks can help you with that as well.
For example suppose you're Acme Widgets, and you want to build a web app, mobile app, analytics, a data lake, real-time stream processing, and all the continuous delivery tooling to go with this.
You can hire ThoughtWorks to provide the team to build all this and also teach your own people how to do it. The pay is essentially the same as you'd pay hiring your own employees for the project, i.e. time and materials.
The advantage of hiring ThoughtWorks is when you want a team of people who all know how to work together, and you want the team for a specific project goal.
An example that may be useful for the Hacker News readers: suppose you work for a San Francisco startup, and you want to ship a product fast, and do validated learning something like the Lean Startup book, or Steve Blank's Business Model Canvas. You can have your own employees building the core product, and you can hire a ThoughtWorks team to build your client apps, continuous delivery pipelines, analytics dashboards, and the like.
Ugh, such a false dichotomy. Does anyone actually think http://nvie.com/posts/a-successful-git-branching-model/ is a good idea?
Instead, compare to any one of hundreds of successful examples on github, all using feature branch based models.
Thoughtworks (and other consultancies that take the CD book to heart) would have everyone pair programming and committing directly to master. This simply doesn't scale beyond a small team. It also actively discourages collaboration across teams, because there is no process in place to review external contributions.
Your 2nd paragraph seems to be saying you dislike the git-flow model, but the 3rd suggests you like feature branching?
Anyway to add my 2c, we use hg-flow at work (git-flow for Mercurial), and it works well for us, because all our repos have a consistent feel to a new dev approaching them -- the 'develop/release/hotfix' streams convey a lot of meaning about the repo's state. Though I should point out we are a small team (<10 active devs), and rarely do we encounter bad merges when we finish our feature branches.
However I've listened to a few good podcasts lately about trunk based development [0] [1] and can see the advantages for large teams (as it forces people to deal with merges sooner, and keep code shippable, instead of deferring them to some nasty, big, future merge).
[0] https://devchat.tv/iphreaks/136-ips-efficient-engineering-pr... [1] http://theshipshow.com/2013/09/branching-merging-and-octopi-...
What is your definition of "small"? The projects I worked on at ThoughtWorks for over three years numbered in the dozens of developers, all pairing, and all committing directly to master.
Thoughtworks was one of the implementors and I was with another vendor. Thoughtworks had 'agile coaches' on the team who would dictate process and alienate anyone who wasn't from thoughtworks, only thoughtworks employees had access to their 'mingle' project planner where they would do all the planning. One of the main objectives of these 'agile coaches/architects' was to make sure they lock down this big client for future projects by integrating themselves deeply into clients processes and alienating everyone else. Their commercial products like mingle are explicitly designed with this in mind. Their 'take over' phase also involved binging in lots of young consultants who would work really long hours, most of them on my project were fresh college graduates from their bangalore/pune office bought overseas on L1 visas who work 12-14 hr days.
Anyone who questions them would be labeled not 'agile' enough and by extension a liability to the project. I left the project shortly because it was not my battle to fight. Employees who worked there associated agile with consulting company scam. It was disappointing to see agile methodology being coopted by consulting companies for their own ulterior motives.
Thoughtworks was just another consulting company who uses 'agile' to out maneuver their competitors. I always wondered why thoughtworks is considered to be different from other companies in the class like accenture/ibm. I've never used a product or opensource project made by Thoughtworks.
This was about 7-8 yrs ago so things might be different now, not sure if they still doing their agile stickh.
Nope, that's still the status quo. I have workd alongside them on and off for the better part of 10 years now, last time a year ago, and this happens every time on multi-vendor projects. I struggle most with pair programming - it is divisive.
That said, also last year, I worked with a guy from Thoughtworks who had real issues with stand-ups. Too much ceremoney, he said. I hoped at the time it was a bit of reality setting in, but not sure how far-reaching that is.
Definitely not NIH. Many new tools in CI/CD space clearly acknowledge Go as the one of the first tools in the pipelines and CD area. While ConcourseCI looks good, even Jenkins 2.0 cannot compare to the first class pipelines support in Go.
Disclaimer: ex-thoughtworker.
Have you tried GoCD? It has first class support for pipelines - not just via plugins, but built into the domain model.
If you think Go was the first tool in the CD area, that probably says more about Thoughtworks defining CD as whatever-we-say-it-is, rather that the capabilities of a specific tool. It's not that people didn't do CD before 2010. It didn't bring anything new at the time. I suspect Go would have fared better if it was a Jenkins visualization plugin, there it could have ridden the coattails of its DSL system. Jenkins is the PHP of CI/CD and you need to go above and beyond it if you want to replace it. I would love, for example, to see Ansible/Red Hat bring their automation experience to this space. Imagine a CD Tower plugin, or a build system where not just the dependecies are declarative. I haven't had the opportunity to use Concourse yet, but I'm sure I will.
I think it never had a chance. With the old waterfall model, projcet managers had some power : they could continuosly interrupt engineers and ask them to do more and more since project went in one trajectory for years. They were justified since the engineers had plenty of 'downtime'. Engineers had some power, the project never changed direction and they could work out the design and implement it carefully, managing technical risk.
When Agile came along, the idea was to change direction every two weeks, but within the two weeks the team does not take on any distractions. I suspect this delicate balance of power was created, not out of a sense of fairness, but for efficiency. But when the people in power saw this they said : 'I will take these parts of the methodology that are useful to me and ignore these parts that are not useful'. Cue the 50 point stories, sprint abortions, mid-sprint story additions etc. Question the reasoning and you are labelled anti-agile. I suppose this was the only way it could go.
[1] http://blog.toolshed.com/2015/05/the-failure-of-agile.html
At one of the clients I was working at, they bought in Martin Fowler to the site, who was being touted as one of the 'inventors' of agile methodology. Agile was being sold as a silver bullet and thoughtworks the deliverer of the software nirvana. the irony of "Individuals and interactions over processes and tools" was not lost on anyone.
I've seen the opposite more often: Many a waterfall had poor assumptions made up front without a lot of technical risk management afterwards beyond "helicopter parenting" from architects.
Most successful agile teams I run into, engineers hold most if not all of the power to design and implement - the product owner wields ultimate power over function and priority.
"When Agile came along, the idea was to change direction every two weeks, but within the two weeks the team does not take on any distractions. "
That's Scrum's approach. Modern XP Shops I've tended to see adopt iterationless approaches, where there is a retro and planning session every week or so, but not really to recognize "iterations" per se. Features are delivered when they're delivered, deployments and releases are automated so they can happen whenever the product owner wants.
Biggest point of success, however is to eliminate project management as we usually know it. There's a product owner, and a product manager and they are usually an empowered customer paired with someone that knows how to build "products", ie. A focus on learning and testing rather than the certainty demanded of most projects. Project managers become at best glue players that protect the team from organizational antibodies.
This such an important and overlooked aspect to learning. Also one of the best things I experienced when working for a startup. For whatever reason I found the environment much more conducive to experimentation and failure. A working POC could change the direction of a project. Most things didn't seem possible anyway, so why not try?
Now at $BIGCO projects take a long time to start and are generally not full of surprises. A change in direction would probably be perceived as a negative of not thinking out your design more carefully.
This seems like a naive point of view. In any real organisation people naturally form hierarchies, even if they're implicit and unstated. It's just human nature. Then if someone lower in the hierarchy starts to suddenly act like a leader they'll have other people who are notionally higher than them in the hierarchy stomp on them, quelling the usurper initiative in order to maintain their own position in the social hierarchy.
This is such a deep part of human nature that people don't even know they're doing it. It's well documented in psychology texts but for some reason people deny it happens in their own workplace. Yet I've observed it happening in every workplace I've ever been in.
If you're a golden child, you'll have praise heaped upon you for whatever you do. If you're not one of them, you can take charge and go above & beyond if you want... but probably no one will care. So at least for me, I really question the value of doing those things nowadays. I just do my work, try hard to do a good job, help out if I'm asked, and that's that.
The worst aspect of this dynamic is when you see one of the "more equal" people doing something that's going to cause pain and trouble down the road, but you know nobody is gonna listen. That's life as an engineer I guess.
This is his statement:
> People can demonstrate acts of leadership regardless of their title and can do so in many different ways, simply by taking action on something without the explicit expectation or request for it.
A simple example of what he's saying would be a person driving a change. Some of us, developers, probably have been in a not-so-great situation (e.g.: build takes too long, culture of not writing unit-tests/automation-tests, etc) and occasionally there's this one passionate individual that starts a movement slowly but sure in order to change the situation to a better one.
I think that's what he's saying.
What you're saying is probably akin to someone lower in the rank starts telling everybody including his/her supervisor/leads how to do their job properly in order to fix the situation... :D
Some people love it to the point of religious fervour, while other hate it as if it murdered their mom savagely. So make sure it looks right for you before applying for a job there.
Architects make the best decisions when they code
In the Tech Lead courses I run, I advocate for Tech
Leads to spend at least 30% of their time coding.
Spending time with the code helps build trust, respect
and a current understanding of the system. Making
architectural decisions without regard for the
constraints of the current system are often bad decisions.
In a startup the CIO / CTO can be coders (they may be the other partner in a 2 person company). But in a company that is 12 years old, they should be at the point that they have high level/high talent people doing those jobs.
So I would expect that they have a CEO that runs the company and a CIO that runs IT and architects that do systems / application architecture. Not spending a day and a half each week cranking out code.
I am a fairly experienced JS dev and I can't imagine retiring to a hands-off architect role in that world, because there are so many tool choices and options in terms of programming style (even languages that compile to JS), so I feel like I need to be regularly writing 'app code' to know how to advise my teammates well.
Saying 'though shalt write TypeScript and use these libraries, and these OOP practices, and structure your app in this way' would feel fairly obnoxious if I wasn't working with the team, with those technologies to write actual code myself. If my teammates instead wanted to do functional programming in Elm, and all I could offer was hypotheticals as to why that was a bad idea, I really wouldn't expect my teammate's respect, and would expect them to be quite-rightly put-out.
Whats the new universe of tool in your space, is one of them going to help you? Is it something you should pilot/plan for, keep an eye on or ignore?
You need to focus on that and figure that out. Having you work on tickets or new features isn't the best use of your time. Working out how it all works (and works well) together and where the holes are is your prime function.
Let's talk about the "Thou shalt". That's when you lead the education process. Why AstroScript is the way, what it will do, how it will work, how it scales, etc. You get some level of buyin and once that's done the team rocks and rolls in that effort. You want to help out with the first set of features fine, but once they get going let them go and get out of their way. You then look for the next thing down the road.
Hey your team wants to do Elm? Is that in the plan, have all the little nuances been looked at, does it scale, etc. etc. Yes, then go that way. No? Then it's up to you to either close the gaps with Elm or put the ship back on track. That's what architects do.
I understand people ending up as "white board architects". They suck, they happen. You can be "hands on", be an advisory, be a resource, be involved with the team. But you shouldn't be cutting daily code.
Lastly, I want to repeat that the original article is about a company that is 12 years old. Well past a few developers, a company that wants and should be on a growth path. Scout around and look at some Y successes that are $100+ million companies. Track their architect(s) down and ask what they do. If they are spending 30% of their time doing app-dev write back to me. Happy to treat you to dinner anywhere in Philly.
What are your lessons learned on how Architects should keep up (and avoid becoming whiteboard architects)?
My personal realization is that it is necessary to be hands on to understand new technology rather than just reading up documentation and others' opinions on such technology.
One of the best things was posted by sheepmullet
Don't give them any actual authority.
Next is go make friends with the operations people. Learn how operations works and what they do, how they monitor, how they keep things running. While they appear to be BOFH like, when they get the idea that you are listening to them, they will help you out. Make sure someone from OPS is on your consensus team. I had a white board architect (WBA) work for me and I made him get signature approval from OPS on everything he proposed. After awhile he got it and became less of a WBA.
Do lots of proof of concepts to see if what you are thinking about will work. In the past I've had a cadre of co-ops / interns do the grunt work. They are always excited about working with a new technology.
(If you are in the Philly Area, call Drexel University. You can get co-op students year round in either 3 or 6 month increments. Pro tip: Don't hire them until after they graduate. If you don't send the co-op back to the University so the Uni can get the rest of their money, they will stop sending you co-ops. )
The other advantage of co-ops is that you can afford to go down some dead ends. It's a win-win, you use a less expensive resource to find out bad news, the co-op gets to put "Worked on Astroscript at major company" on their resume. It's very freeing because you can then take on someone from the outside going "Hey lets do Elm", assign an co-op to do most of the grunt work rather than burning your time up.
You can be as hands on as you want. I've always found that getting some new tool installed is a huge mess. Need this library and that version of something else, these scripts don't work, etc. So my co-ops do that. Once it's spun up and running and their first mini-Proof Of Concept is working then I'll get involved with a larger POC and get my hands dirty.
(An aside on the install mess. When we get ready to start the "Moving to Astroscript" to the internal consensus cycle, I assign a co-op to package it. They put together a clean setup process for both Operations and the Dev Manager to sign off. Nothing kills a project faster than the people you want approval from not being able to spin it up to look at it.)
It's mostly lots and lots of talking to people about what their pain points are, what direction the business is going in, thinking about planned and unplanned pivots, etc. Always be thinking about a Plan B.
My check list for new things (in order) * What business value does this bring (ROI) * How does operations run this * What is the Disaster Recovery Plan * What is the opportunity cost * What is the internal friction * What is the external friction with our partners
Other things that may help:
Start a series of brown bag sessions (your call if the bags contain lunch or beer) and present out to anyone what you are thinking about. ( Tip: Master the ability to create a 50 minute long Powerpoint in 30 minutes. )
Talk to other architects / users that are using the tools, designs, etc. and see what they are finding out. Be ready to share back what you find. "Hey our review and POC of Astroscript figured out that getting any useful logging out of it was impossible, so we are punting"
Be a nice person. And remember, someday you may end up working for one of those co-ops.
Dont give them any actual authority.
If they want to drive architecture in a certain direction then they have to convince the senior developers, project managers, and tech leads to follow them.
A project fails. It is an expensive failure. Fingers are pointed. Lessons are "learned".
"Never again!" is the cry.
A new project is authorised. More effort is put into the front of the project, because that's what the classic software engineering literature says you must do to avoid costly failures.
The budget is bigger, but that's OK, because it's being spent on requirements analysis and some architects to Make Sure It Goes Right This Time.
The project fails. It is an even more expensive failure. Fingers are pointed. Lessons are "learned".
A new project is authorised. Even more effort is put into the front end. Even more money. "This time we're going to hire Senior Architects!".
Firms that used to be accountancies, but have now discovered the lucrative value of having interns move boxes in Visio while billing out the Senior Architect for $800/hr, are called in to help.
The project fails. It is an even more expensive failure. Fingers are pointed. Lessons are "learned".
A new project is authorised ...
It's easy enough for me to buy.
To me, "Architect" has become an anachronism, it dates from a time when programming experience was thin on the ground, and languages were very low level, requiring a lot of bit twiddling and optimization to be viable. Under those circumstances, it makes more sense to have someone laying things out without writing any code. These days, I just don't see the point.