Can they work together?
Lots of our people have lots of opinions. Here are just a few of them
ThoughtWorks embraces the individuality of the people in the organization and hence the opinions expressed in the blogs may contradict each other and also may not represent the opinions of ThoughtWorks.
Blog post by ThoughtWorks Studios
21 May 2013
Blog post by ThoughtWorks Studios
21 May 2013
To document the general process of creating automated test scripts for web applications with Ruby and the WATIR testing module. The intended audience of this document is QA engineers/testers that are going to be either creating automated test cases for their applications or testers that are going to be running and maintaining already created tests. This document assumes that the reader is already familiar with the basic methods and syntax of the Ruby language and the components of an HTML based application (links, forms, JavaScript, etc..)
Blog post by ThoughtWorks Studios
21 May 2013
So how do you do great design in a rapid, multidisciplinary and inclusive way? How do you set up new projects for success in a fast moving, agile environment? How do you ensure shared understanding and ownership of new initiatives in just a few days?
I now focus a lot of time on facilitating collaborative design workshops, and other methods focused on quickly creating a shared understanding of objectives and buy-in for and execution approach.
Blog post by ThoughtWorks Studios
21 May 2013
Longwood Gardens, PA
Blog post by Martin Fowler
21 May 2013
Brett’s article on the Dependency Inversion Principle (DIP) and how it works in practice has been a popular read on this site (over 24,000 views since it was published at the beginning of the month). Brett has now expanded the article with two more examples from his delivery experience: questioning requirements and handling time.
Blog post by Martin Fowler
21 May 2013
- Liked – things you really liked
- Learned – things you have learned
- Lacked – things you have seen the team doing, but consider that could be done better.
- Longed for – something you desired or wished for
Blog post by Paulo Caroli- Agileretroactivities
20 May 2013
I have done 3 projects in a row where we did not use story points and simply counted stories. I’m a big advocate of that approach. Let me explain why.
I'm an estimation geek who loves the nuances of estimation, and have used function points, use case points, COCOMO, and story points for over 10 years. Over time, I’ve become convinced that the more we estimate past the very initial point, the less accurate we get. Additionally, long-drawn, “scientific” estimation exercises generate wrong expectations of certainty.
Blog post by ThoughtWorks Studios
20 May 2013
In a previous life, at an R&D engineering company, there was a comprehensive culture of code review. I saw three different approaches across three teams while I was there.
The first team was a mix of embedded systems and embedded applications. This team had a very strict, very rigourous code review process. Every task had an associated review. All reviews were pre-commit (completed before merging work into trunk.) Reviews typically had two reviewers. Reviewers were assigned by the tech lead, based on a combination of appropriateness and load. All reviews were conducted using a dedicated newsgroup (remember those?)…
Blog post by Giles Alexander
19 May 2013
There’s a recent blog entry on the ArtLogic.com site about learning Angular. One aspect of it resonates with me:
“Quit jQuery for a While”
It’s true. You could well be used to having ‘on click’ equivalent event that mutate the DOM, and think that you could well mutate Angular models instead. That’s the path to more JavaScript than you need, and you’ll never know the low/no JavaScript idiomatic to Angular at entry-level.
I think of it this way: With Angular, model objects (POJOs) can drive views without JavaScript being involved. Similarly, views (via Angular’s expressions/bindings…
Blog post by Paul Hammant
19 May 2013
We are a software company and a community of passionate, purpose-led individuals. We think disruptively to deliver technology to address our clients' toughest challenges, all while seeking to revolutionize the IT industry and create positive social change.
Sign up for our perspectives newsletter