Different Roles in a Full Stack Team

I don't think life is a box of chocolate. But it keeps surprising me never the less. In my case that means that I keep finding value in different activities. Such that I have not done myself or that my teams have not done very much. Maybe it could be best described as evolution.

I started as a coder. Although people didn't say it out loud (often), making modifications to 'the core' was more spectacular than making modifications to the graphical user interface. Mostly the illusion came from the siloed organizational structure. People who do something like to think they are somehow better than those 'other people' who do other things. Which is silly, of course, but still very human. :)

But anyway, I was a core developer. I worked with a big legacy core and could do magical things with it. I could create new features and implement new parts according to the details people gave me. Testing was something that was often mentioned as a valuable thing, but generally praise was given more to people who coded.

At some point I started to realize that testing is, in fact, important. My code wasn't perfect. My mind, the mind of a coder, was thinking how the system should be used. I didn't give a lot of thought to how the system wasn't supposed to be used. But many times users come up with very creative ways of doing things if the tool allows. When someone tested my code, it became better. It had less bugs. So testers were, and still are, useful.

When you work as a group or as a team it makes sense to have someone who makes sure that things happen. I don't think it needs to be a coach or Scrum Master (but it's ok too). More senior team member with right personality and skill-set can be even better.

Then lately, since Apple introduced iPhone, usability has become increasingly important. If the team has a dedicated designer, that's truly awesome. But even having usability built into the working practices is good. It's easy to get carried away with improving the algorithms and trying to write really clean code, but forget the fact that in the end someone should be able to use the system. And hopefully be able to do it without consulting a thick manual. So design and usability are important too.

Finally comes the role of architecture. It's possible to live without named architects, but I don't think it's possible to develop software with multiple teams if the architecture is neglected. Architecture might emerge, but it might not be the architecture you want to see. I dislike the idea of lifting architects to a podium or letting be live in an ivory tower. In my view architect could be a role. For the sake of clarity it would be just good that someone (even if team members take turns) will check occasionally the big picture and make sure all development efforts serve the grand plan. So I consider architects to be important too.

As a conclusion my view of different (necessary) roles in a team has changed over the years. Originally I thought only coders were needed, but now I know it takes a bigger family to grow flourishing software. And in this post I've intentionally scoped out many important business roles. Without proper Product Management and sales there probably won't be anything to develop. But let's leave something also for the future. :)

Do the Right Things Right and Fast

It's fascinating how sometimes some relatively simple picture can contain so much relevant information. I have been lately involved in strategy renewal and while doing that I saw a picture that I fell in love with.

My job is very much concentrated around improving software development processes. In essence it's about doing the things right. But many times I have thought that it doesn't really matter if you do things right if they are not the right things. You might write the most beautiful and simple code ever, but it makes no difference if no one cares about it. I feel this is often a problem with some open source projects. Okay, there might be open source with crappy code quality too, but usually the quality is on a really nice level.

Another case are commercial projects with tight deadlines. In those cases it's easily right things (someone, usually customer, is really interested about the results), but just fast. When coders are stretched, it is the quality that suffers.

By concentrating on the software production methods (Continuous Integration, Continuous Delivery) and good engineering practices (craftsmanship), one can only reach adequate results. One dimension is still missing.

Maybe the best non-perfect position to be is when you have a good portfolio (you are doing the right things) and you concentrate on your code quality (doing the things right). At this point you can still miss valuable market windows, but it can still work. Then you can start investing in the production methods and speed things up until you hit the sweet spot in the intersection of all the three dimensions.

I thing this later triplet of circles depicts the situation at practical level. When your Product Management is working properly, your Developers are applying good engineering practices and your development infrastructure is in order, you can expect awesome results. I'm not saying it's easy to achieve but definitely worth a try.