Software development hasn’t existed for all that long now, maybe 60 or so years. Things have changed a little during that time, and some things have come full circle. One significant shift that has occurred, is a change in how we think software work should be done. This shift can be seen in the way our development teams are put together.
Just the programmers
In the beginning, there were just programmers. Software was about engineers building stuff for themselves and other engineers to help them do engineering stuff. At this point, other modern roles like designers, product people, and testers didn’t really exist.
The engineers discovered a need, figured out some way to solve that problem, and implemented a solution.
There also wasn’t a whole lot of software being made at this time. There was a chicken / egg problem of not enough demand for software and not enough people to create software (which would create that demand).
Something big happened in 1958. While working as a manager of Operating Systems Development for the Mercury project, the first human space flight program in the US, Gerald M. Weinberg created the first independent team of software testers. Jerry brilliantly recognized that testing was a specific skill, and also that it was a complete role that a person could fill full time.
This split had huge effects around how teams were commonly put together up to the early 2000s.
At one of my early jobs as a software tester, the teams were physically separated. Developers were in their area of the floor, testers were usually off in another area. Each group had their own respective managers that would gather info from the workers and then use that to figure out what was going on. Business folks were on another floor all together.
Building software like that was tough.
In 1970, Dr. Winston Royce published his waterfall paper which described each stage of software development as a distinct, non-overlapping phase. This seemed to also create the idea that the work that goes into software development should be distinct and non-overlapping.
Bringing things back together
In February of 2001, a group of people came together to craft and sign the agile manifesto. The intent of the manifesto was more far reaching than how a team put together, but it had profound effects there. Agile gave people the idea to start working together once more. fewer (metaphorical) walls, less bureaucracy preventing people from doing work. In agile-speak, this is called a cross-functional team. The idea that everybody on a team can do any given task and no one self-identifies as any particular role.
At another gig a little bit more recently in my career, the entire company was working remotely. There was no physical office. There was an expectation that everyone would be available on skype during business hours except for vacations and such. There were no barriers to us working together, at all. This changed how I thought about team structures. In the beginning, this team was very small and often working on the same feature till it was in production.
As the company grew, the idea of very small teams producing software every couple of weeks stuck.
In his new book, Ron Jefferies suggests creating very small feature teams. This is similar to the the agile rhetoric, but my understanding is that a feature team here consists of a group of specialists that can complete a feature. Programmer, designer, product person, tester, dba, …whatever, all sitting together, building software.
This is not the common way of building product right now, but it is a fascinating shift from where things started to where we are now, and where the industry is moving.
Where we are now
What we’ve got now, is lots of software companies taking lots of methods and structures and ideas from different places and hybridizing them. Each time a new hybrid method appears, there is some physical artifact of that that appears to us in in our team structure.
More to come.