Team-octopus – an anti pattern?

Many of our daily stand-up meetings and much of the daily over the desk communication sound like:

– “Somebody needs to update the QA database

– ”The regression test fails
– “What version of the application are your testing, did you make sure it is the latest

And the classic:

– “I have installed the components locally and it works on my machine

We also have more severe issues, in SCRUM these are called impediments, these are for the SCRUM Master to handle and might require help from people outside the SCRUM team or even escalation.

All of the examples I gave above are not at this level, they can be handled by the team and they should be handled by the team, but sometimes they fall between two chairs. In order to not confuse these with impediments I will call these obstacles, they can be overcome, but do require some effort.

Now lets set the stage.

We are a small team. We are all experts in some areas and weaker in others. At the same time our team profile consists of a set of functional roles, making sure that all the required aspects of our software development strategy are covered.

The team has grown over time and from time to time we have had consultants working as team members. Some of us have been with the company for a long time and others shorter. This mean that apart from what the individuals bring to the team based on education and prior experience, accumulated knowledge from our company also plays an important part on what and how we contribute individually.

All in all this gives a nice balance and after many failures, experiments, constellations, planning, retrospectives, changes, adjustments we have a good proces for developing software.

But it is not perfect.

Our biggest hurdle and what actually means that we have a low bus number for some parts, is the stuff that falls between chairs, the tasks that are on nobody’s job description, the stuff that glues everything together, the invisible workings of a modern software team.

Our team comprises of the following:

  1. – 1 Team Manager
  2. – 1 Front end UI / UX developer

– 3 developers
– 2 testers, where 1 also acts as test-manager        
– 1 Product Manager – that is me 🙂

The product manager and front end developer design the features and the developers develop and testers test. Our team manager sees to that operational issues are addressed in balance with new features and everything is pretty smooth sailing – well apart from what seems to be a never ending backlog, but that seems to be a part of the game.

This is a good setup for a making software releases, bug fixes, new features, but it does require that the infrastructure for developing software is in place. Here I mean:

– Ticketing system
– Version control
– Build system
– Continuous Integration System
– Test systems (applikation servers and database servers)

Our ticketing and version control system is under control by our operations department and works pretty much all the time. In case of problems we simply raise an issue and it is addressed.

Our build system is highly integrated into the applications and frameworks we build and is based on the platform we deploy to. So this is under version control and works quite well. At some point we experienced a lot of issues when Apple cut the ties to OpenSSL, which we solved by introducing Docker for the developers and that work quite well – but more on that later.

For CI, we also have a pretty stable setup. Once in a while our builds break. Often we can blame the culprit, based on the commit that triggered the build. Sometimes our test environments fail or a timed CI job fails, there are many reasons for this and often it is based on changes to example data or that more than one team member is working on the same dataset. There are multiple ways to overcome this and there is probably a nifty technical solution we can apply – well we have one issue where a download of an external component can render our Jenkins setup unresponsive, which still confuses me as to why this is even possible, but we have only observed it a handful of times.

All in all we have a well functioning team, development proces and infrastructure.

But I do observe the following problems:

– When stuff breaks out of the blue, it tends to fall between chairs
– Non-product code maintenance seems to be of nobody’s interest
– Maintenance of the shared databases are nobody’s responsibility
– Long term strategic ownership of the development platform is of nobody’s interest

I love building software and I love the whole SDLC and I often end up addressing the stuff listed above – which is bad because it is not in my job description, but I am simply the most senior on the team and it is my cryptonite, in that sense that I simply cannot leave it alone when it is not working, perhaps I should get professional help.

Which brings me back to Docker – which is a good example.

Docker saved us in a situation, where maintenance of development environments was consuming a lot of hours due to problems with our stack. Apple had cut the ties to OpenSSL, so all of our local development environments were experiencing issues. Luckily we deploy to Linux, so we weren’t experiencing issues there.

So I introduced Docker and we could get moving, it required a lot of experimentation, we learned a lot, but we got is stabilised and we have things under control.

This made me think that Docker could play a more prominent role – yes, I think long term about the development platform and deployment platform, simply because I care.

– What if we could skip the whole deployment packaging strategy we have today and simply use Docker images for deployment?

It is hard to make such a push ahead when it is not in your job description, it requires time and effort, way beyond introducing Docker in the development team, because it involves managers and other departments.

– What if it didn’t?

If you look at the team rooster and some of the problems, perhaps an operational profile in the team could do the trick, if the team was expanded with a devops role.

Historically we have a tight separation between operations and development due to IT-policy and standardisation emphasising this.

Currently our release proces is quite cumbersome and involves a certain amount of red tape, yes it has improved, but it is far from you one-click deployment and even continuous deployment setups you hear about.

– What if we could deploy Docker images directly into production?

This would most certainly be a boost to the feedback loop and therefor the team and then the productivity.

– But is it a good idea? – teaming up with roles with specialties in certain areas are a good idea, we can see from our current team what specialists can contribute with, but shouldn’t we aim for a better integration with our existing operations team?

If you look at the team we have no support function, our organisation only has a first level support, so we act as 2nd. or 3rd. level depending on how you depict it. What we did here was quite interesting, we made the support role go on tour in the team between the developers. This has increased the knowledge sharing and responsibility. I cannot take credit for this our current team manager introduced this, but I do wish I had introduced this years ago…

So perhaps the right solution to addressing the problems we face are applying the same strategy for the operational responsibility, I think this is called devops. So the team can handle everything by itself – problem solved!

I am still pondering about my role as a product manager, how far should I tage it. I see a lot of roles becoming abstract and facilitating roles – and I am simply not that type. It does not work for me, perhaps it is my techie background, but I need to have a more low-level understanding. I act as sort of an architect for parts of our systems and one thing I have picked up is, architects who do not code, loose the coupling to thing they are architecting. You should not be a code contributing team-member, but prototypes, examples etc. can be coding without interfering with the day to day software development cycle.

I am still trying to find my area as a product manager and I might come back to this in a future post. For now I am trying to get the team to find out how to overcome our obstacles…

Team-octopus – an anti pattern?

What does full-stack developer even mean?

I see the term full-stack developer everywhere, this got me thinking:

What does it even mean?

To recruiters it seem to say: “we want somebody who can do everything“, meaning we want to hire somebody being a perfect match no matter what, perhaps even in context of wherever technology would take us.

To developers however it seems to communicate that a developer is capable of handling the ability to work in all tiers of a given stack, meaning front-end to backend, UX implementation to datamodelling and everything in between.

The two are actually not far from each other, but … what stack are we actually talking about when we say full-stack and is this even possible?

Lets start by examining what a stack is.


Traditional LAMP Stack

There used to be a term, which you do not see so often anymore, since it has somewhat been booted by the full-stack term and that is  LAMP (Linux, Apache, MySQL, and PHP, source: Wikipedia).

The top-layer of the stack can be replaced by a suited language like Perl, Python and possibly even Ruby), meaning that the definition of the LAMP stack is not even entirely clear – but this is a basic traditional stack and possibly one, which was and still is dominant in many workplaces, simply due to it’s popularity and wide-spread adoption.

Abstract LAMP stack


Since however the LAMP stack is a bit ambiguous lets break it down. From an MVC (Model-View-Controller, source: Wikipedia) perspective it would look like this and we get recognisable depiction. This makes it a bit easier to identify the tiers of which the stack is comprised – let be get back to this later…

As mentioned the  LAMP stack is still around in some sense, but the classical representation does not really depict the more fine grained stack predominant today.

A 6 Tier Stack

Due to the Javascript revolution a large part of the stacks in production today can be broken down even further, Javascript was doable and used earlier, but not to the extent and in the same way as today. Taking this into consideration it is possible to do a more clear distinction.

6 tier stack

The controller/view tier, is much more well-defined and can be sub-divided on technologies, the distinction is not really communicated by the traditional LAMP stack, even though this possibly has been a more or less the de facto standard, having Javascript play a larger or smaller role based on adoption.

MEAN stack


Which brings us to another very predominant stack – the MEAN stack (MongoDB, Express.js, Angular.js and Node.js, source: Wikipedia).

The MEAN stack is a Javascript centric stack and the hard part when talking about a Javascript centric stack is the sheer number of variations based on frameworks etc. and the combinations possible, but the MEAN stack is very popular and seems adopted widely.


The abstraction of this stack demonstrates a very interesting aspect of the more modern stack – the separation from the operating system. Of course there is a an operating system beneath the stack, but in general it does not play as significant a role as earlier.

Abstract MEAN stack

This whole discussion on the significance of discussion the operation system as part of the stack is interesting, unfortunately the topic is beyond the scope of this article, so I will leave that stone unturned.

Yes there are alternatives and there possibly as many variants of this traditional stack as there are software teams/developers/PaaS product managers. I have attempted to annotate the 6 layer stack, with some technologies just to give you a picture, there are languages/technologies that I have unintentionally left out, forgotten or have not heard about, fill me in in a comment – but lets move on.

Annotated 6 layer stack

To get back to the question on: “What does full-stack developer even mean?” Building on the figure above, you would have to select a set of technologies to represent the 6 layers of your stack and then you should be able to work in all tiers of a given stack, meaning front-end to back-end, UX implementation to datamodelling and everything in between.

What I have observed is that these stack-jumping super-developers do not really exist.

Each of the stacks requires specialist knowledge, since they are technologically very different. If you look at a single tier, like the server logic tier, all of the languages mentioned derive from the language C and have so much in common it is almost just a matter of syntax… *ahem* Javascript is derived from C and all in the same category, so we can actually collapse these two tiers into one. The separation was only aimed to represent the two functional areas.

Based on the above plethora of choices, I do not think it makes sense to talk about full-stack developers in general, unless you are very clear on what stack you are talking about. Yes you could go for the most prominent stack or buy into some specific eco-system. I have chosen not to touch on the Microsoft stack, since I have no knowledge of Microsofts current offerings in this area and the same goes for Java.

Developer Origins

I have observed is that developers come from somewhere. They have played around with some technologies, languages, frameworks, applications, operating systems, a stack, while they learned their way around computers. Then they got a job or an education and got exposed to new technologies and possibly even new stacks.

Some developers are be top-down, they originate from the front-end, design, UX/UI or some industry or education related to visual presentation or they just started working with websites and at some point needed some more functionality.

Others are bottom-up developers they originate from Systems administration and operation, which mean they now the OS and they now the applications part and all the operational aspects of modern applications. Perhaps they even originate from database administration meaning they are strong on data-modelling etc.


The type I most often see is the diamond developer. These are classical computer programmers. They program and that is what they do. They originate from classical programming and at some point, they needed work with data so they got exposed to database technology. Later or before they get exposed to the concept of users  (other than themselves) and they had to create a proper user interface.


There are of course exceptions to all of the modelled developers I mention above and you can vary the size and contents of the different tiers, where some diamond developers excel in several interpreted and compiled languages, even other language concepts than the traditional procedural/OOP programming paradigms.

No matter where you come from, your perspective is unique and your toolbox is unique.

Full-stack Polyglot Specialised Generalist Developers

What does full-stack developer even mean?

It is a developer capable of working the different tiers of the stack and who can understand the different paradigms and technologies of which the tiers are comprised at the same time utilise best-practices and embrace requirements and who can consolidate everything into an application (on schedule, budget and with minimal defects and maximum security).

Just kidding…

Developers are a special lot. We specialise in our tools, we get thrown a problem and We have to understand the problem and the problem area. Which mean we have to become specialists in this particular problem area. When we solve the problem we get thrown a new problem, perhaps in a new job, gig, project and we have to become specialists again, but we often reuse our tool chain, which all of a sudden become a general tool. As we evolve with problem solving we extend our toolbox – we become specialised generalists or general specialists.

So to rephrase the question, does Full-stack Polyglot Specialised Generalist Developers exist?

I have met many extremely talented, clever and resourceful programmers over the course of my career and I hope to meet many more.

My conclusion is that the term full-stack developer has to take the following into account:

  1. What does the stack comprise of we are talking about
  2. How many variations to the stack have your shop/project made to the stack
  3. What is the prominent stack on the market

Then we have a slight chance of talking about the term full-stack developer and be on the same track, but at the same time this does not even make sense as a general term – developers evolve, stacks change, due to developer evolution.

The stack of yesteryear might be the legacy system you have to work with as your next problem area or you have to work with the untested error prone top-notch newest stack on the block designed especially for the problem at hand.

Stacks are just bundles of tools. Focus on problem solving, extend your toolbox, become a specialist, have a general perspective on technology and choose the best tool for the job. You will encounter numerous stacks, you will by far not become a specialist in all of them, some you will love, some you will hate, but for most you will do both since there are no silver bullets in software development – but there are plenty of problems, tools and the fantastic gratification of providing the solution.


What does full-stack developer even mean?


I fell over something on Github called TIL (Today I Learned). I have for long pondered to migrate my notes elsewhere – currently they are all collected in a Wiki.

The idea of TIL intrigued me and now I finally got a TIL repository set up. Currently it only contains one TIL, but I plan to evaluate and migrate my earlier notes to this more open and accessible format.

Here are some of my first impressions of doing TILs hosted at Github instead of something else.

  1. The are public available
  2. They have native version control (they are actually contained in a Github repo)
  3. The can be written in Markdown
  4. They can use syntax highlighting based on the languages supported by the Github platform
  5. They follow the normal workflow used for other projects I have hosted on Github
  6. They can be forked and merged
  7. They can be commented on using issues (not directly linkable, but I guess it is somewhat trackable)
  8. Did I mention they can be written in Markdown 🙂

I have not observed any major draw-backs of this kind of write up to now, some will probably show later on, but I will give it a try and if it does not work, well I can find some other way of hosting my notes, hints, tips and tricks.

Only one TIL, but I promise more will follow.

Take care,



On the move…

I have had several blogs over the years, now after a long blogging hiatus I decided to start a blog with I have used WordPress in the past with success and it is a nice blogging platform and it integrates nicely with external tools like MacJournal etc.

My previous blogs have been on technology, the internet, computers, programming, software development and other things related and on topics I find interesting – and I expect to continue with these topics, since they are my current interests.

If I get the time I will migrate my old blog posts here just for the fun of it, but it will generally be a blog on day to day stuff on the topics I previously mentioned.

The title for the blog is lastmover, should have been last-mover, which is the opposite of first-mover. With technology and life developing so rapidly it is often difficult to keep up, so why not just face the fact that you (me that is), is never going to be a first-mover, but a last-mover – and I have no issue with that.

So welcome to the last-mover blog – feedback is always welcome, even if it is just speling corrections.

Take care,



On the move…