Saturday, October 30, 2010

Prevent Burnout : Continuous Integration 2.0

Into - What am I talking about now ?

In a previous blog post, I talked about burnout from my own perspective of having experienced it, an overview of it after the fact, and some techniques for getting though it.

The two main pieces of feedback I received were firstly “get a proof reader” and secondly “how can one stop or mitigate burnout in the first place?”.

The first I've done (and I’ve also signed up for a writing class), so hopefully my writings will get better and be easier to read. The second point I have been thinking about for eons, and performed as a job, so will share my thoughts in this post.

To frame the topic and post, I'd like to share an anecdote from my counselling schooling:


I remember discussing the ethics of being a counsellor in class, and causing some commotion as I stated "Surely it's our aim to put ourselves out of a job".

I didn't mean that I wanted to see the whole class (or profession) jobless and destitute, more so the manner that care is predominantly provided, i.e. remedially.

It makes no sense to me, to wait for something (a person, a system, a server, etc) to be overwhelmed by challenges and then do something about it. Especially when you know the challenges are coming. Be that life challenges in general (personal skills), lots of clients to a web site (performance engineering) or anything where you have cause and effect.

I say “Prepare and be aware as you go”, and drastically lower the chances of it happening in the first place.


I would like to explain what I've learnt from building resilient software and technical systems, and combine it with some counselling theory, then apply that to a team as a whole, be that a development team; or any creative group.

Hence, the meaning in the title: Continuous Integration 2.0, continuously taking care of the team and it’s integration, during the process of building.

Most people like me now build software such as SaaS, web sites, etc., which is continuously worked on, and is only ever “done” when we never work on it again. It’s a marathon, not a sprint to the finish, though in either case you have to be up to the challenge.

The thought of running a marathon with no training or support boggles the mind, so why do it in life and work?

What is CI (Continuous Integration) and why do it?

CI is an approach to building (software) systems that involves the continuous checking of what is being built. This is to ensure that it's doing what it is designed to, and not exhibiting the kinds of symptoms that you don't want, i.e. bugs.

I've done this for years with software and have tried to extol the virtues of “the output reflects the way in which you do something” in places I've worked (with various degrees of understanding and acceptance from those involved, I must admit!)

Ironically in some places, CI is ignored or sidelined in favour of chaotic rushes to an arbitrary deadline. And upon reaching that dead line, the output is... well, chaos. That kind of project and management truly get what they ask for.

Quality and speed of development go hand in hand, now and in the future of the project. Remember the majority of the work starts when you launch, so lay good foundations.

Catching issues early saves so much time, energy and cost, be that in software or with people and teams: “A stitch in time saves nine”. Read up on “technical debt” and the costs of bugs, they are both well documented.

Not only is there financial cost to a project, though there is emotional cost (leading to burnout) for the people working on the software. Which is the part I’m more interested in.

In practice (for software and technical systems) this typically involves pieces of code called “test units”, that continually (i.e. automatically) test the code as it changes, i.e. to make sure that two plus two still equals four.

Being predominantly a PHP person, I use which in itself comes from CruiseControl, which I'm a big fan of.

So what we're doing is checking in often to check things are okay. The approach being a lot of a little opposed to a little of a lot.

What is the “team leader's” role to help stop burn out ?

I suppose you could have a program that emailed everyone asking “Are you okay?” every day, though that isn't what I'm advocating !

Also I believe that “once-a-year team building” isn't as effective as doing it continuously, as it's the integration of the team you're hoping to facilitate and achieve. Curious, there are those two words again.

I believe the once-a-year approach or “when it seems necessary”, is done more out of a sense of obligation, or to copy-cat other companies, inferring truth by constant assertion. I think it should be done all the time, opposed to sporadic knee-jerk reactions.

Team building is a facilitation role, and has more to do with supporting people than telling them what to do. Some projects use an Agile technique of daily stand ups, though these can seem forced a lot of the time. Also they tend to interrupt people, and force a rigid working structure irrespective of what is actually going on in the project.

I suggest it is a role of the team facilitator to take care of the people, usually they have titles such as “project manager”, “team leader”, “technical director” etc. Unfortunately they usually loose site of the fact that it's their responsibility to be focused on the people and then process, so the people can focus on the project.

Don't constantly interrupt to ask if they are okay or be forced in what you are doing, humans know when they are being dealt with in a inauthentic manner. The specifics of people skills and how you check on people are down to personal style and technique, I'm just saying make sure you're doing it.

Do less better, remember a lot of a little opposed to a little of a lot. It’s the responsibility of this role to continuously integrate the care of the team, into the daily project.

What can the individual do ?


In brief, keep all things in balance and perspective for mind, body and soul, in all areas of your life.  

Yes, I know, it’s a lot easier to just write on a blog than to actually put it into practice!

Though in practical terms, I believe that any situation we find ourselves, we are 50% responsible for being there. Now that doesn't necessarily mean when something is done to us, we are responsible for that. Though how we choose to react, or act is up to us. As is how we choose to prepare ourselves for situations we enter into.

So we have a duty to ourselves to take care of ourselves. Also being aware of those around us who might be overwhelmed is no bad thing. If I’m in a team of 10 and I’m mindful of the rest, and they do the same, that means there are 9 people keeping an eye out for me.

I believe that it is unethical and unprofessional to work when compromised in an emotional manner. You are not going to doing good work, be happy, or doing anyone any favours including yourself. You are likely just compounding the negative issues.

Here are some topics and activities to think about to help mitigate burnout out. I’ve combined what I do, what I've been taught, and what I've found in my studies :

This is where we start, as this is where the embers of burnout will flare up from and affect         the rest of our lives. Great skills & activities to read up on and explore here are :

  • Meditation  - Not for everyone, though having chilled downtime is no bad thing
  • Hobbies  - I do lots, they distract me from work and allow me to reflect & socialise
  • School - Learning different skills and topics good outlet, broadens the mind and outlook
  • Self talk - I’m my own worse critic, I have to watch being negative, and see the good too

When we have no energy, are lethargic, are experiencing poor nutrition this will obviously effect our ability to function. As well as being prone to illness and injury. I’m not a gym rat, or advocating that everyone should be, though making sure we take care of the physical sides of our beings is just important as the others. As we have to be in balance, It’s how well functioning systems work.

  • Food - Volumes have been written on the benefits of eating well and cutting out junk
  • Exercise - In a sedentary job that most in offices have this is vital
  • Check ups - Not being a hypochondriac, though a health and eye check is no bad thing
  • Sleep  - Exercise helps here, also natural sleep not 10 beers at the bar type of sleep
  • Massage - After training as a masseur, I extol the virtues of it to everyone !


Not  always the easiest topic to talk about with a target audience who, in my experience are typically not so spiritually inclined. Though I don’t necessarily mean just religion, but include meaning, purpose, a sense of being and belonging. Having studied psychology and worked for a company who’s mission it was to ease the effects of social isolation (and they are harrowing believe me ), I think not paying attention to this area is a big mistake.

  • Friends & Family - Including personal relationships, ensure you give them time & attention
  • Spiritual - I like reading about Daoism, though this is personal to each person, obviously
  • Cat - The benefits of caring for a pet are well documented, as well as fun
  • Volunteering - What do you give back ? Doesn't have to be formal or organised

As an experiment, I suggest you keep a record for a week just to see what time and effort you put into each of these areas. Then ask yourself is that what you consider balanced, and is it how you want to be ? What could you do more or less of ?

What are the warning signs, and what shouldn’t we do ?


An absence of the things noted in the previous sections, I suppose. Be aware of the environment you are in, are you being supported or pushed? Be aware of how you feel, is the pressure relative to the reward or investment you have, or are you killing yourself for someone else’s profit.

By way of a personal example, here is knowing you’re not cared about :

In a previous job I ended up working 3 weeks straight including evenings, posting on forums doing customer relations and support, on top of the “day job”. In a meeting I mentioned I was looking forward to an upcoming holiday as it was also my anniversary. “The boss” laughed and said I’d likely being working as he had profit targets to meet, and that I had to sort out the technical problems he’d introduced to the project before I got there.

I decided to leave that job at that very moment.

That is just an example of an external bit of proof of the environment you are in, personal ones to watch for include :

  • Stress - Personally I feel it quite physically,
  • Lack of sleep - I ether can’t sleep, or can’t get out of bed
  • Constant  tiredness - Related to the above, though adds to lowered performance
  • Self medicating - Be it alcohol, substance, sex, etc, you’re treating a symptom

To continue on the self medication point above, there is also prescribed medication from doctors. Though personally I’m not a fan of the “pop a pill” mentality and culture, I would never advise anyone to stop who’s on medication, as I’m not a doctor. Though I’ve  found there is a constant focus on treating the symptoms and not the actual cause (good for drug companies, bad for people). Though there is an argument that if the drugs can alleviate the symptoms enough so the person can deal with the cause, then fair enough.

Being a fan of CBT (Cognitive Behavioural Therapy) I always try to deal with the presenting symptom, but also find out the root cause, which is creating the presenting symptom,  much as is done when debugging software. Then the cause can be addressed so you don’t have to deal with the symptom continuously.

“Why is this happening, how can we deal with it and how can we prevent it next time”.

Conclusion - What am I saying


Try to stop it happening, don’t try to “fix it” once it’s over whelmed. It’s the principle of continuous integration, be it with software, teams or people.

Much the same as the saying “It’s about the journey not the destination”.

Take care of yourself, it’s professional and ethical. We can't do anything else properly without doing that first. It’s not at all selfish, to not do it I would suggest is selfish.

Don't work for abusive companies, or greed-focused ones (i.e. beholden to shareholders). Easier said than done obviously, though when weighing up two job offers, which one is really better, given the points above. I recently just ended a very lucrative contract, as the bad far outweighed the good.

I sleep rather well now.


Take care of yourselves, keep and eye on others, and keep on building good things in good ways.


Saturday, October 23, 2010

Healthy creation of technology

After the last posting I received a challenge from a reader (Shane Simpson) who happens to be the hosting company I've worked with on a few project and continue to do so as well as recommend.

The tweet was this one, which made me think of words by Ben Harper, “what good is a critic with no better plan.", a valid comment I thought, so I tried to summarise (some of) my ideas.

Now this is going to take some thought, and answering .......

I think I will try and answer the question opposed to being too exploratory, so "what you feel is a better way of running a technical company" which to me infers, "how to be successful, happy and sustainable as an individual at work, as group of people (the team) and ultimately commercial organisation, after all there are bills to pay".

A short answer of the top of my head, is healthy relationships between people and a common purpose, the long answer on the other hand is a journey though systems analysis, conflict management, communication, finance, ergonomics, logistics and a host of other topics I fear.

Though as with any journey this (assumption and idea) is where I'm starting and I'll just have to see where I end up.

Opposed to trying to describe how I see the whole process & system in one go, I'll take the scientific reductionist method to being with and break things down before putting them back together again as more of holistic view. As with the integration after analysis done, it will be easier to see the important bits, how they interact (the social & technological relationships).

1. People

A vast topic that been talked about since the beginning of time (OK well nearly) and posted about by the likes of Richard Branson, who I think has a fair idea about building business and dealing with people.

1.1 Which people

But whom ? Easy answer is everyone, though it depends on the role(s) people have, in UML it would be actors, and what point in time. To just simplify things for now down to builders, facilitators (which isn't a mutually exclusive role, I enjoy doing both) and clients (internal & external, as I also use the code I write, look at 37signals !).

1.1.1 Builders
The people that put the bricks together and build the wall, the coders, the chefs, the architects who draw plans for the train, the welders that put it together, the electricians that wire it up, the people who have a conscious, deliberate and actual input into changing the essence of an idea into something tangible.

The point here being a thought or desire is being realised, be that in code, brick or a metal tube that whizzes along on tracks. For our answer, lets just call it, code. Though I include art and digital assets anything that was created that is going to pass though a network card to a client in 0s and 1s.

1.1.2 Facilitators
Personally I'm not a fan of the term "management" I share the same thoughts on them as most experienced software engineers and professionals like Dr Paul Thomas. My recent employment history has given me enough evidence to see what happens to technology when people in that role forget what their tasks are (and not constant interruptions or making implementation choices). The tasks are quite simple :

  • Support the team
  • Deal with paper work (licenses, formalities of business, road blocks, etc)
  • Get the above annoyances out of the way of the builders
  • Ultimately get yourself out of the way of the builders, you will slow them down and frustrate them.
  • Facilitate communication between the people that need it.
  • Observe from a distance.

I think the hardest thing for people in this role from what I've seen is, trust.

Trusting the builders are capable, trusting the process over all (i.e. not micromanaging), trust in the truth that it's OK to make mistakes and to lead by example as that's where a lot of learning comes from. Sharing a mistake, learning from it and the working as a team to build on it in a trusted environment is an amazing experience and to be supported.

The other end of the scale is an experience I had in one organisation where a tester wanted to create a league table of which coders had the most bugs buy way of a punitive tool a "blame board" they called it; something I didn't allow at all, a very negative environment.

I suggest doing a course in group counselling or group facilitation, the things I learnt from Prof. Ross Laird at VCC when studying counselling were quite profound.

I try to never tell people what to do or "mark them" on the outcome, just communicate the goal of the project or desired outcome and then leave the builders to the task of translating that information into the end product. Though of course you observe and deal with the flow of the process in the moment, though you trust the builders.

Never tell someone to "take ownership" of something, firstly it's condescending and secondly what you are actually saying is "take the responsibility for the past failed decisions".

Trust is a huge topic within itself, though it's two way and built on respect (not demanded, i.e. authoritarian).

1.1.3 Clients
The end users in most cases, the people with the cash ! What I've found in successful projects (e.g. the early days of vBulletin) is that the initial idea which the builders create once accepted and used by a growing base of clients, is in part given over to them.

They have valid input, the are now a part of the system over all, they have a valid voice, and can & will walk away from negative relationships where they aren't heard (most of the time). Just look at the positive atmosphere and relationships between clients & builders (and facilitator, being Ashley) over on It's basically a nice place to be, the trust and respect talked about above is evident and being earned by both sides.

At a previous games job I used to spend hours on the forums as Technical Director talking to the players, understanding their concerns and frustrations and communicating what was going on. While most of this effort wasn't able to be understood by "management" the outcome and following that built up in a short period of time was more that enough positive proof with in itself.

So the point here, is that clients become part of the group once the product is out and the communication between them and the inner team (lets call them) is tantamount to success.

The art of communication is listening, NOT talking non-stop, being the "leader" in a meeting and power point .....

1.2 Timely focus

In something of a rebuttal to “the customer is always right” or “the customer is at the centre of everything”, I'd say it depends on what is going on, what is the focus of the process and system at what time ?

In a perfect world, effort and energies would be balanced amongst the needed areas in a harmonious balance. As it is focus in a project usual varies depending on what stage it's at, to belittle builders about support or customers before a product is launched is so pointless it doesn't need commenting on.

So be aware of what it is your doing, when, and why. If you believe you are focused on one stage or group, then be so and accept that not all your energy is going to be available for other tasks.

So the point here is stay in the moment, be present, keep a focus on what is going on; Do less better, not more worse.

2. Agreed outcome

In the book Thinking in Systems, Donella Meadows lists the top attributes of successful systems, one of the, is : “Goals – The purpose of function of a system”.

She also goes on to explain the importance of having all the sub systems (i.e. all the actors & tech systems) aware of what the ultimate goal is.

And it isn't “making 1 million dollars a month”, I can assure you, that's nothing more than the cry of green from short sighted management. Profit is a side effect our outcome of the system working to purpose and customers exchanging money for the output of that system (i.e. what ever it is the business makes or provides).

2.1 Beginning

In the beginning stages there is the original concept(s) very broad based ideas and a hunt for direction or a market, this isn't the time to start coding trust me, this is the time to question, explore, play with ideas, observe others, play games with ideas/situations/outcomes.

Ideally this behaviour in some form is ongoing throughout the life time of the company, though you can see when it shifts from one stage to another due to the amount of change and team consensus there is.

2.2 Middle

Stage 1 has given way to enough of a consensus to begin building. I'm not advocating water fall design methods (or any other) here, a method is a social tool or organisational one, I'm talking about a state and activity.

Here concepts start to be pulled out of the air and realised in 0's and 1's on a data store some where. This is where the facilitators have to put their ego to one side and let the people who actually build things get on with it, though typically this is where the most damage is done my suits with constant meetings, attempts to micro manage and constant changes (because the first step wasn't allowed to complete enough).

2.3 End

Everything to now has been laying the foundations, getting the technology ready for clients input. That can either be beta testers, going live straight away, internal review or a combination of all. Though by End here all I mean is end of the internal team, as you're just about to include the external team.

A lot of projects getting stalled here or held onto for too long as it's the “constant polishing stage”, no set goals or consensus in achievement is met. Which is the typical side of the builders, the opposite end of the spectrum is pushing out unfinished systems far too early, which is symptomatic of amateur and greed drive management. The pull between both forces is evident in most places I've observed.

Though when there is a common level of trust and it's seen as a constant process between professionals this is a a much more pleasant experience !

So points to remember here, is being aware of where you are on the time line and that builders who are supported naturally want to achieve and do well (aside from being a human trait)

3. Facilitation & Support

In one of my other posts I explain how support (in a typical hierarchy org) is top down and responsibility is bottom up, I have had a few experiences of it being forced the other way, where I was made to support the ineptitude of those “above me” and take responsibility for their choices (legacy issues in a project I didn't build, culminating in getting taken off a project which I was saving, and ultimately saved with my plans …. also being bad mouthed to the whole team in an ego speech, who luckily knew the real story, I walked away from that one instantly !!).

So, the facilitators are responsible to the team, and take the responsibility for their choices.

4. Flexibility

There is an analogy used in parenting styles that explain being too rigid is like being a brick wall, and that being too loose is akin to being a jelly fish. So there is either far too much control or there is non what so ever, or in the case of teams and systems, boundaries.

The ideal compromise (in the analogy) is that of a spine, it's protective and flexible, though to a point.

Much is the same with projects and systems, having a vision and goal is good to start with, though all things change once they are in motion, and going with what is in the moment as long as it isn't destructive can be very worth while. It's also how a lot of scientific discoveries are made.

5. Assessment

There is a fair amount of honesty that is needed when doing assessment, it can be uncomfortable to shine a light into corners of an organisation, though ultimately ourselves. Though to know where we want to be, we have to know where we first are. And that is as individuals before the rest of the team, if what you're doing isn't authentic to who and what you are, then your outcomes will be limited.

How many times have you done just enough to get the job done to get by because you're not really engage in it ?

What that engagement is, how it can be fostered, is a whole book in itself. Though it has to be authentic, you can't just demand that team members engage wholly.

Though without being honest about where you are, you'll be on the wrong path and confused at the outcome when you get any where.

A company that is constantly looking for “A players” …... when the company it self isn't an A place, because it doesn't embody that philosophy is going to be a poorly operating system over all.

6. Trust

Likely one of the hardest things to do, to trust in yourself as well as others. Though in the most productive environments I had very high trust in not only the abilities of the people I was in a team with, though in their engagement and their openness to questions and learning as I was. I made mistakes, was supported, felt valued and ultimately safe.

And all that came from mutual trust within the group, we shared a common goal, felt supported, were flexible and honest about out abilities and expectations.

7. Money

Oh the sordid topic of coin; be how it comes in, what it does and where it flows out.

Ultimately be reasonable and see it as a something you get for a well functioning system, not the output of the system itself. This can be gauged by competition, the market and the usual supply and demand factors for the most part.

Pay as per the RSA clip pay people enough so it's not an issue, skimping on pay up front as a way to “save money” is about as counter productive as you can get, and once again a greed motive from management.

As for reward, I remember a meeting where developer reward was being discussed and it was being forced by management and peers that the bonuses to developers should be based on company profit “while they had no input to the way things were done or even what was being done”. So they were held hostage to the poor choices of management/producers/et al.

Putting it all together

Sorry, but there is no magic formula, “Agile” isn't a magic silver process bullet a lot think it is, it's just another organisational tool, it's not a guarantee of anything, as with any other method.

I think my initial short answer holds mostly true, it's about people and communication. Add to that awareness of the system as a whole to each part and a focus on the direction things are going in and it's a matter of being present and staying in the moment for decision making.

I've found that the quality of the output of a system, be it software, social, family, etc is a representation of the quality of the relationships within the system. Now there are some execptions and you can force good things out of a bad system by chance, though it isn't sustainable or at all enjoyable, so aware people won't stick with it.

Getting good people, focusing on communication (and quality of it not amount or volume !!) and capture of ideas, aligning them from a know starting point in a given direction, creating a trusted and safe environment (include ergonomics in there as well !) then getting out of their way and facilitating where it goes seems to be the best tactic I've found.

It typically comes back to one word that you can apply to any member in the team, or how they treat each other, or develop the communication and system interconnects, the system itself or ultimately the output, respect.

Any other questions find me on :

Thursday, October 21, 2010

This code has no value

"This [any] code has no value"

Since I've been encountering the games world and how they deal with software this is a term I've heard a few times, along with "Oh the tech is always messy, it's just the way it always is". It's rare you see such a good example of "truth by constant assertion" or a system that is in a race to the bottom.

Opposed to answering a claim that is little more than an excuse not do to a decent job, it's likely better to figure out what is the "value" that is being talked about as there are a few kinds.

Firstly there is the cost of the end product, how many hours at what salary rate etc, plus over heads and what ever added and draining costs unnecessary suits are going to add. That at least will give you a raw currency cost. Misleading most of the time I've found (i.e. oh it's expensive, it must be good), though some what necessary in the world of commerce.

Once there is a product, there is the value to the company of what can be done with it. Can it be licensed and re-sold, used internally, white labelled etc. Though this within itself is dependant of the main thing that will bring down nearly all forms of value, Technical Debt.

One of the comments I hear that made me think about this post was leaving a company with another developer and he said "Oh they'll be pulling teeth for months, the code has no value without the developer who wrote it".

I instantly thought : Typically not, good software is build with the design, layout, architecture, comments all rolled in and part of the whole process. Otherwise all you're getting is the last 10% of the work, the implementation once all the logic has been thought out choices made.

A developer is paid for 100% of their time and then project (you'd hope !) ..... so why is the company only after, or thinks it only needs the 10% ?

Impatient, naive and poor management is the usual answer I've found.

I've had a few experiences where software people are treated as workers on a production line and you just throw more of them on, or "make" them work faster to get more output. Now given that most places fall into that counter productive mind set and treat the process of creation like Victorian work farms, I can see the logical next step that what ever "comes out the end" is what you want.

This is also reinforced by middle management "producers" and the like, who believe they are actually the ones making the choices on how the work is built. Funny and shocking I know.

An aside ........ though a good segue into what I think has value and how the value can be keep in the project separate from the developers, though obviously heightened with them about.

Given that any piece a substantial code will pass though a few if not many hands in its life, and it's only ever "done" when it's never worked on again, lots of people are going to have to read though, modify and most importantly understand it.

The thinking that went into the creation and the way the logic was solved is what has the most value, what language your using doesn't have that much impact (part of what irks me when people become evangelical about their tech over any other, i.e. the Ruby or Druapl mobs). Communicating why something was done and a brief explanation of how will reduce the learning curve of the next worker dramatically.

And what are the two main things that typically poor management do to projects ? Demand that coders start work instantly "what's what we pay them for" ..... i.e. usurping design. Then making up arbitrary time lines which make the developers curtail efforts and compress the working style into :

// Does things
$storeforrandomtime = $foo->bar($t)->hammersmith($e) * $varfromthreefilesago;

I've been on projects looking at code worse than that sat next to the "manager" who paid for it explaining that it was going to take a few months to clean up to be workable with, the only reply I had was "Yes, weeks right, don't say months" ......... sufficed to say I left that chaos pit!

So what would make it all different ?

Firstly, a recent project I'm working on has a strange thing called design ! The data layer is designed, the business logic, all the APIs and data flows are done. The whole thing presents itself transparently, you can see near instantly where everything is, and more importantly why. The choices and ideas of development are communicated. It could be in PHP, Java, Erlang, but the essence of the project is there.

It's only the very junior developers and armature management that accept anything else as a job done well.

It's more a case of capturing why not what, and during the design phase as well, not the implementation phase. Another reason why non-engineering "management" should stay away from the wonder drug that is "agile" development ...... lack of understanding and ability to gauge impact on architecture.

Misuses of agile has given way to the same symptoms as the greed prevalent in the financial systems of the world ...... short term gains and sly deals at the expense of anything sustainable and on going.

Secondly make sure the ideas and creation steps are seen for what they are, opposed to being done during the same time as implementation (and I don't mean prototyping).

Third, have a think about what it is you're actually paying people for ........ are they making widgets or using skills and experience to make decisions, that need to be recorded.

It goes beyond "Oh just comment the code" ........ though for some that would be a good start.