Happiness Optimization

playwork.jpg

The hiring process for a new employee costs about $4,588 in the US [1] or £5,311 in the UK[2]. For Software Developer roles the cost might be even higher. Moreover, when we add additional costs like salary, taxes, benefits, training and equipment we will end with quite a big sum spent on a single employee.

Big companies and corporations try to lure the best candidates with a wide range of benefits and competitive salaries. In addition, each candidate is sifted through a complex and involving interview process  for only the best employees to be chosen [4].

The only thing which companies require back is a productive employee generating profit…

Unfortunately they tend to forget the most important and obvious fact:

A happy developer is a productive developer

Or perhaps, of more relevance, is the negative of this sentence:

An unhappy developer is an unproductive developer

This article will discuss some practices which may lead to the increase of happiness and (effectively) productivity of software developers in a company. It is impossible to cover all of them in only one blog post, but I believe that these are the most important ones.

Trust

Build projects around motivated individuals.

Give them the environment and support they need,

and trust them to get the job done.

Agile Manifesto

The most important part is to trust each and every new software developer in a company. We should think about them as artists or craftsmen doing their creative work and we should always give them room for problem solving.

Trust in your employees is sometimes more than that. When the level of trust is high, programmers start to feel unique and energized. With many challenges to work on, we are creating space for growth and self development. In addition, by giving time to simply play, hack and work out potential solutions, we are more likely to get them in the most (and probably the best ) productive state of mind – Flow [6].

The most interesting example of trust-building that I’ve seen was what Nordstrom tend to give their employees on the first day:

Welcome to Nordstrom

We’re glad to have you with our Company. Our number one goal is to provide outstanding customer service. Set both your personal and professional goals high. We have great confidence in your ability to achieve them. So our employee handbook is very simple.

 We have only one rule: Use good judgement in all situations.

Please feel free to ask your department manager, store manager, or division general manager any question at any time.

Tools and a Process

 In addition to state of flow and hacking, we should always provide programmers with the best possible tools and adjust the whole software development process to their needs.

According to  this  discussion, we can split programmers into two groups.

The first group loves playing with their toys. They view creating a software like a sandbox in a playground, so providing them with new tools, equipment and giving them possibility to create “cool” things means a lot to them. (If you don’t support my claim then why would programmers spend hundreds of hours discussing which text editor is the best [7]?).

Moreover, when a team is provided with inadequate tools or forced to use specific tools or when there is only limited number of licences available, programmers will start to feel like replaceable components. For example, in many financial organisations and bigger corporations you cannot install your own software without permission from management.

The second group loves delivering working solutions and is driven by a feel of accomplishment. They are focused much more on a bigger picture and they seek reward in form of appreciation or self-fulfilment from their achievements.

 This part is very well discussed in video on RailsConf 201by Chad Dickerson, CEO of Etsy [9]. He discussed performance of factory workers in early 90s and used some ideas related to software development:

 “The traditional assembly line deprives the worker of satisfaction… by the confinement of the worker to one manipulation repeatedly and endlessly which denies the satisfaction of finishing a job.”  [9]

He discussed an interesting story taken from a book [10], where workers assembling parts of the aeroplanes (modules like engine, wings etc) were unsatisfied and productivity started to decrease. They resolved this problem by organising a meeting with pilots in planes and having discussion about which parts the workers were working on. After this productivity raised, because they were given a purpose and a sense of meaning.

“If companies really want their workers to produce, they should try to impart a sense of meaning – not just through vision statements but by allowing employees to feel sense of completion and ensuring that a job well done is acknowledged.” [9]

 Lastly, I would like to point, that no matter what, every programmer loves to work with certain type of equipment. It is viewed by them more like a lucky pen or certain routine which is necessary. We can find plenty of examples discussing what equipment and tools a programmer is using in new company on their blogs [11]

Working Hours

One of the most obvious, yet another one which is often forgotten by employers, is allowing programmers to work for no more than 40 hours a week. There are three important reasons behind this.

 First of all, programmers are often working on creative things. In order to solve problems they need the full firepower of their brain and a different way of seeing things. It is impossible to come up with the perfect design in one day no matter how much time you spend on it.

Secondly, when you work for a long time you start to make more mistakes. It may be the case, that instead of producing good code you are injecting bugs into the code, which might be difficult to find and not easy to repair.

Lastly, it is all about knowing what a team can produce with sustainable pace without depleting their energy resources. Instead of working 80 hours a week for a month before the release of the project and crashing afterwards it is better to work 40 hours a week for two months. This approach will definitely lead to much better results and higher team morale [12].

Other sources also support the 40h/week regime:

From The Art of Agile Development [15]:

“When you make more mistakes than progress, it’s time to take a break. If you’re like me, that’s the hardest time to stop.I feel like the solution is just around the corner—even if it’s been just around the corner for the last 45 minutes—and I don’t want to stop until I find it. That’s why it’s helpful for someone else to remind me to stop. After a break or a good night’s sleep, I usually see my mistake right away.”

 From [13]:

“1. Improve focus.  How many people can claim they have 100% focus every day, 40 hours a week?  Focus is absolutely critical in building quality software and it’s something we should absolutely optimize for.

2. By giving your employees a little more time for themselves they’re able to take care of personal errands during off hours.  And that’s exactly how it should be anyway.”

Eat Together

Something about sharing meals breaks down barriers and fosters team cohesiveness. Try providing a free meal once per week. If you have the meal brought into the office, set a table and serve the food family-style to prevent people from taking the food back to their desks. If you go to a restaurant, ask for a single long table rather than separate tables.

The Art of Agile Development, Supporting Energized Work p. 79-80 [15]

 There are plenty articles on the web about benefits of eating a dinner with your family [14]. Some of them are applicable to team members too. I would personally say that there is nothing in the world which boost team morale, cohesion and spirit rather than lunches together.

Let’s look on this from another angle – providing good communication and integration within a team is extremely important – after all the team is developing a software together. If most of “socialization” takes place during mandatory meetings over a conference table, it is much better to build some relationship over the lunch table.

However we should have a look on much more than eating together. Giving your employees nice and comfortable place to eat and rest is extremely important. Every human being needs a break from time to time, so having a place designed especially to that will be beneficial and probably this is a reason why we can find examples of colourful offices from Google, Facebook or Amazon.

I would say that we should go much further than that. Providing your employees with free lunches and onsite cantinas may tighten bonds much more. After all, there would be a place where your employees can eat, chat and have fun together. In addition, providing them with free lunches will save the time for going to grab takeaways [11].

Conclusion

There are a lot of examples of a good techniques and practices which can lead to productivity boost. Some of them are obvious (but still a great majority of employers are not following them) another are vague and it is difficult to see explicit connection to productivity.

Aforementioned practices may have a much bigger impact on programmers’ performance than increasing salary, which doesn’t always work in boosting productivity. Even when it does, it is usually in short term. Creating energized atmosphere and controlling developers need will help to boost their productivity, design and code quality.

This might be a reason why most programmer would rather work for Google, rather than Banks, even if salary in the first place would be a lower.

References

[1] Hiring an Employee: How Much Does It Cost?  – http://homepages.uwp.edu/crooker/441-so/articles/ats-workforce-121500-c.htm

[2]http://www.hrmagazine.co.uk/hro/news/1020605/talent-aquistion-costs-rise-uk-gbp5-311-hire-compared-gbp2-226-us

[3] How Much Does An Employee Cost? – http://web.mit.edu/e-club/hadzima/how-much-does-an-employee-cost.html

[4] Cracking the Coding Interview: 150 Programming Questions and Solutions

[5] On Developer Happiness and Productivity – http://ilikeorangutans.github.io/2013/04/03/on-developer-happiness-and-productivity/

[6] The Flow – Programming in ectasy http://psygrammer.com/2011/02/10/the-flow-programming-in-ecstasy/

[7] Editor War – http://en.wikipedia.org/wiki/Editor_war

[8] Respect People: Trust Them to Use good Judgement –  http://management.curiouscatblog.net/2010/10/28/respect-people-trust-them-to-use-good-judgment/

[9] Optimize for Developer Happiness at Etsy – http://www.youtube.com/watch?feature=player_embedded&v=22EECFEk9Xs

[10] Concept of the Corporation, Peter F. Drucker

[11] Price of Developer Hapinness – http://officesnapshots.com/2012/03/30/the-price-of-developer-happiness/

[12] What Silicon Valley Developers Can Teach Us About Happiness At Work – http://www.huffingtonpost.com/2013/07/25/what-silicon-valley-devel_n_3644538.html

[13] Optimizing for Happiness in Software Development –http://www.bucketsoft.com/blog/post/optimizing-for-happiness-in-software

[14] The Benefits of Eating Together – http://www.sparkpeople.com/resource/nutrition_articles.asp?id=439

[15] Shore, James. The art of agile development. ” O’Reilly Media, Inc.”, 2007.

Response to “Agile Methodologies in Large-Scale Projects: A Recipe for Disaster”

This is a response article to an  an article Agile Methodologies in Large-Scale Projects: A Recipe for Disaster.

Introduction

People tend to think about Agile as a set of rules which following will lead your team to achieving an easy success. Unfortunately this is not the case as none available software development methodology guarantees success.

The main difference between Agile and other methodologies is focus on its core values described in agile manifesto [4]. Agile creators developed it having in mind some of the important issues reported during the usage of standard development practices. They decided that during the process of software development we should care about three major factors:

  • Creativity.
  • People.
  • Working Software.

First of all, programming is a task much more similar to art rather than any other type of engineering. Code can be written in infinite numbers of ways, so it demands constant flow of creativity from the programmer.

Secondly, we must care about people during software development – Agile is designed to enhance people productivity and maximize teamwork effort. It serves an idea of proper knowledge distribution and setting bonds between team members.

Lastly, Agile designers realised that producing software and writing new code is much easier (and far more enjoyable) than fixing bugs, therefore testing process beforehand is crucial task during software design process.

It is easy to see that those principles can be used both in small projects (where Agile is believed to be designed for) as well as big projects. After all in both types of projects, there is a team of people that want to produce innovative and working software.

 Working Software over Comprehensive Documentation

Author of [1] states that it is far more desirable to work on comprehensive documentation and start with complex planning in order increase chances of delivering a working solution.

First and foremost, big projects tend to fail too often regardless of documentation and planning involved [8]. You can find a lot of examples in the web [7]:

In a landmark 1995 study, the Standish Group established that only about 17% of IT projects could be considered “fully successful,” another 52% were “challenged” (they didn’t meet budget, quality or time goals) and 30% were “impaired or failed.” In a recent update of that study conducted for ComputerWorld, Standish examined 3,555 IT projects between 2003 and 2012 that had labour costs of at least $10 million and found that only 6.4% of them were successful.

This citation can be used as naïve explanation that standard development methodologies do not focus on producing working software, therefore we should use Agile. Unfortunately the answer is much more difficult to form properly.

Looking at this from different angle – Agile does produce Comprehensive Documentation. The documentation itself will be done by properly designed unit tests and by following coding standards (commenting your code extensively). Those things can be then used to automatically generate  proper documentation with minimal effort (eg. Doxygen).

The idea behind “Working Software over Comprehensive Documentation” is to start working on a software development as early as possible, rather than writing everything in specs before the project stars.

Lastly, author of [1] states that when failure occurs, shareholders will try to find explanation. It is implied that without proper documentation there won’t be a proof of what went wrong.

This means that “Working Software over Comprehensive Documentation” point was misunderstood by an author of [1]. There is a program documentation and process documentation. These two are completely different and serve for different purposes – one is used to produce software another one is to avoid structural issues. The second one will be used to document the whole process by project manager and it will be a first thing to look for errors.

Individuals and Interactions over Processes and Tools

Agile care about people, because after all it is a Team of people which will produce a software. I would say that proper communication is the most important part of software development in a team, especially important when talking about bigger projects. From [6] we can derive:

Studies of “communication saturation” during one project showed that, when no communication problems exist, teams can perform 50 times better than the industry average

Agile principles were introduced to enhance human interaction and build team spirit. This mean that stand-up meetings, pairing, energized workspace and code sharing were designed to boost communication inside a team.

Moreover, author of [1] says that we should always reuse tools and libraries instead of prototyping them. This unfortunately is also misunderstood – good communication between programmers may boost code reuse, because someone may already know the answer to a problem you are working on. Agile was never about not using existing tools and building them on your own, but about relying on human interaction during data gathering process rather than using sophisticated tools and processes.

I can easily think about an example of relying on processes rather than talking with other team mates. During my summer internship I was a witness of an employee filling bug report on piece of code which was developed by a team mate sitting next to him. This obviously is a recipe for disaster.

In addition, author claims that in larger projects it is wrong to go from standards and use innovative tools. This seems like a valid point in general, but there are moments when prototyping may be useful. Let’s think that there are two possible solution to an existing problem – one will be standard another new and innovative. It may be a case that quickly developing standard solution and testing will enlighten some important faults. We know that this is always difficult to estimate everything beforehand even in standardised big projects [3].

Customer Collaboration over Contract Negotiation

Let’s think about using on-site customer for a minute. Author of [1] explains importance of iron-clad contract in big software projects, rather than using customers to deliver what they really need.

We should stop for a second… We need to deliver a software which is doing what was intended to do. This is stated on a contract…

The idea behind Agile Development is to use constant feedback from customers (or shareholders) and make sure that our software does what it is intended to do (WHAT CUSTOMER REALLY NEED).

Authors of both [2][3] explains a solution during contract negotiation. During planning game project manager (the most important person in the group) will discuss cost for delivering individual features.

In the end – what is Customer Collaboration after all? Let’s say that the goal is to deliver enormous web system – what stops us than to test first features as soon as possible and gather a data from users?

Responding to Change over Following a Plan

Author of [1] claims that following a plan in big projects is a good practice, because everything can be crossed from a list. In addition according to the author in large projects it is much more difficult to set a proper ways of communication.

I would say that it is everyone wish to code everything according to a list. It would make our work much easier (and probably far more boring). Unfortunately even in big projects requirements are vague and not specified very well. By following agile practices we can iteratively prepare demos which may be presented to a customer (or shareholder) for verification.

Communication in huge projects is a significant and main problem for Agile being difficult to implement. Fortunately there are several solutions proposed from Agile experts to deal with this problem. Those solutions introduces a bigger overhead when it comes to software development, but are designed to distribute knowledge among teams and (what is probably much more important) to create a feeling of ownership of the project. One of those ideas (which easily may serve as a topic for a new blog article) is Scrum of all Scrums presented in [9]. The idea can be explained by the usage of Scrum principles for teams in addition to Scrum for individuals.

Summary

It is obvious that Agile is much more difficult to implement for larger project. On the other hand I believe that problems discussed by an author of [1] can be easily solve even in big, government projects.

Agile is not a best solution for everything nor a set of magical rules which grants success to every project. Values written down in Agile Manifesto serve a purpose to focus on extremely important aspects which tend to be overlooked in standard ways of software development methods. After all rules and resources in software engineering are completely different than in electric or civil engineering.

Secondly, big projects tend to suffer from the same kind of problems that the smaller ones. Agile Manifesto described set of rules which will boost productivity of a team, so there is no reason to apply them for everyone. In addition there are a lot of discussion how to use Agile successfully for bigger projects [10][11].

Last, but not least is an idea of applying some agile principles even in standard waterfall process can boost productivity, because we can provide constant knowledge sharing, satisfaction of individuals and much greater feeling of project ownership.

Note

The author of [1] chose very broad subject for his article. It was difficult to answer and discuss every part, so I decided to comment some problems and misunderstandings which may be found in the author’s article . There is much more to be said in this subject, so I am open to discuss points which were only mentioned in this article in the comments section below.

Reference

[1] Agile Methodologies in Large-Scale Projects: A Recipe for Disaster. SAPM Blog, 2014

[2] Shore, James. The art of agile development. ” O’Reilly Media, Inc.”, 2007.

[3] Martin, Robert Cecil. Agile software development: principles, patterns, and practices. Prentice Hall PTR, 2003.

[4] Manifesto for Agile Software Development http://agilemanifesto.org/

[5] What Does the Agile Manifesto Mean?  http://www.scrumalliance.org/community/articles/2013/2013-april/what-does-the-agile-manifesto-mean

[6] Agile Principles and Values, by Jeff Sutherland http://msdn.microsoft.com/en-us/library/dd997578.aspx

[7] Why Do Big IT Projects Fail So Often? http://www.informationweek.com/strategic-cio/executive-insights-and-innovation/why-do-big-it-projects-fail-so-often/d/d-id/1112087?

[8] Why Big Software Projects Fail: The 12 Key Questions  http://www.cs.ucc.ie/~herbert/CS4504/Xtra%20Software%20Risks/laacm0512-Why-Big-SW-Projects-Fail0503Humphrey.pdf

[10] Scrum of Scrums: Running Agile on Large Projects  http://www.scrumalliance.org/community/articles/2013/june/scrum-of-scrums-running-agile-on-large-projects

[11] Yes, Agile works in larger enterprise projects too. http://www.zdnet.com/yes-agile-works-in-larger-enterprise-projects-too-7000020875/

[10] Agility@Scale: Strategies for Scaling Agile Software Development  https://www.ibm.com/developerworks/community/blogs/ambler/entry/large_agile_teams?lang=en

 

Why Pair Programming Is The Best Development Practice?

 Let’s do some pair programming!” – this phrase may one day discourage you from working in your dream software company.

There are many claims supporting extreme programming and pairing in general, but you think that this is not for you.

If you believe that working solo is the best way for achieve great focus in a creative process known as software development…

YOU ARE WRONG!

Cowboys ain’t fun anymore

Recall your best programming experience. Do you remember when ideas were flowing through your head, hours were passing as seconds and you were experiencing constant feeling of a muse sitting next to you?

You might have experienced this several times, but unfortunately not very often. You probably think about programming as a creative process – sadly this is not relevant for every task. What about when you were working on bigger project? Interesting and creative core part was finished very quickly, but what was left as boring and extremely repeatable.

Guess what – your most programming tasks in a software company will focus on boring and repeatable tasks with very few of them being creative and challenging. Your performance will be measured by number of implemented features, lines of code and bugs fixed. In addition hard work will be valued much more than talent on its own. You will not feel productive and creative every day, but you will have to submit your results anyway.

Cowboys are of no value anymore. Heavily trained spec-ops of extreme programmers are.

Not even once!

Now we should hear some arguments against pair programming. Let’s start big [1]:

One of the most influential programmers (if not people) in the world, Steve Wozniak, famously advocates”:

“Work alone… Not on a committee. Not on a team.”

You might also add that some of the greatest minds in our history were introverts and they achieved great success by working solo (Darwin, Einstein, Newton). Of course you won’t mention the fact that those world-changing inventions were then developed, tested and introduced by dozens of scientists, engineers and businessmen, but it sounds like a good point against pairing in general. Lastly you may mention that about 30% people in the world are believed to be introverts [2] (and probably even more when we think about programmers), so pair programming must be a practice introduced by extroverts to control a process of software development.

Every claim mentioned above is probably true. We can all agree with them, but it doesn’t change values which may be gained from working together.

Let’s change our direction a little bit. Ask yourself extremely important question:

Have I ever tried pair programming?

If the answer is no – you should stop reading and try it. If yes and you are still not convinced – go to the next section. Maybe this is a case that you are doing it wrong.

Pair Programming 101

There are tons of examples and blog posts on the web of people sharing their bad experience when practising pair programming. There are thousands of stories of how evil pairing is and how wrong it is for creativity[1,3].

Let’s stop this. I believe that those stories exist, because people have no idea how to practice pair programming.

No one was born the best programmer in the world. People who are believed to be ones, gained their knowledge through hard-work, experience and hours spent on coding. The same goes with Pair Programming and social skills in general. Everyone needs some training.

Let’s consider some of the most important rules [5]:

  1. Pairs should be formed flexibly and naturally, rather than by fixed assignment.
  2. Keep fresh perspective by switching your partner frequently.
  3. Sit comfortably (with plenty of space for your feet and arms) side by side.
  4. Always use a big monitor (or more) and two keyboards.
  5. Collaborate with your partner, do not critique his work

Following those four important points should help you achieve success when working in pairs. In addition, we should consider a little bit more.

Pair programming is an important and crucial part of Extreme Programming (XP) methodology. This being said, we cannot use pairing without following rules from XP.

What XP tries to do, is to enhance team software development process, rather than single programmer process. XP shines in every piece of software that must be maintained (eg. development code). It means that spiked, innovative solutions  may benefit much more from different approach (eg. happy hacking).

Let’s think about Test Driven Development – it was invented to simplify and control development code with hundred (thousands) line of code. TDD works as milestones – one test resolves one problem. This means, that it give structure to your (unstructured) flow of thoughts.

As mentioned before, XP is team software development methodology. In a team everyone is average (or as good as weakest member). In order to make people better, we must follow a strategy when matching people into pairs. Let’s try to match people with the same skills in the beginning. Later on we can try junior plus senior programmer. This however must be realised with cautious – let’s give junior time to research important part of the project, which no one is expert in (eg. library). We should make everyone feel like an expert!

Last, but not least is to practice proper ways of communication. You may say that during pair programming people may start arguing or feeling bad. I will tell you – this is a problem with your team. Teambuilding is important, the same as practicing good manners. If we resolve this – we will resolve every problem.

We need a proof my dear Watson

There are plenty of articles, research and blog posts supporting pair programming. Pairing is all about collaboration and teamwork, thus it will shine when following aspects are considered [5,6,7]:

  1. A huge percentage of bugs and defects can be caught before release.
  2. There is a lot of knowledge sharing and project ownership involved in the process.
  3. Code design improves with significant reduction of number of code lines.

Those points will serve as a something well defined and thoroughly researched. In addition several well-known and respected programmers prefer pairing [5,6] and even more experienced developers may benefit from learning a new ideas.

The biggest objection against pairing is that it doesn’t leave you time for though. Demarco and Lister, in their experiment [8] found that the best factor for quality is not money nor experience, but how quiet the workplace is.

On the other hand, according to [5] people who are practising pair programming are experiencing flow (productive state of mind) more often and are experiencing less interruptions than solo programmers.

As the last proof, let’s hear some comments from people who used pair programming [6]:

The adjustment period from solo programming to collaborative programming was like eating a hot pepper. The first time you try it, you might not like it because you are not used to it. However, the more you eat it, the more you like it.

“It is psychologically soothing to be sure that that no major mistakes had been made . . . I find it reassuring to know that [partner] is constantly reviewing my code while I drive. I can be sure I had done a good job if someone else I trust had been watching and approved.

Is there an ultimate answer?

Yes! There is an ultimate answer to the question “Why Pair Programming Is The Best Development Practice?”. However the answer is a tricky one:

Pair Programming is the best development practice, because it is fun!

Pairing is not most suitable in every situation nor easiest one and probably not even the most effective one. It works well, shines in standard team software development, produce good results and strengthen team spirit. However the most important argument is that pair programming gives us a lot of fun, knowledge sharing and motivation in imagined-as-single-person task such as programming.

References

  1. http://www.bennorthrop.com/Essays/2013/pair-programming-my-personal-nightmare.php
  2. Schat, Sean. “Quiet: The Power of Introvert in a World That Can’t Stop Talking.”Brock Education Journal 22.1 (2012).
  3. http://mwilden.blogspot.com/2009/11/why-i-dont-like-pair-programming-and.html
  4. Shore, James. The art of agile development. ” O’Reilly Media, Inc.”, 2007.
  5. Cockburn, Alistair. Agile software development. Vol. 2006. Boston: Addison-Wesley, 2002.
  6. Cockburn, Alistair, and Laurie Williams. “The costs and benefits of pair programming.” Extreme programming examined (2000): 223-247.
  7. http://www.codinghorror.com/blog/2008/04/core-war-two-programs-enter-one-program-leaves.html