Tragedies of Performance Evaluation of Software People

I'm constantly having conflicts with managers who insist on backward methods of performance evaluation for agile teams. It is one of the miseries of software teams, because in most cases, such methods demotivate individuals and undermine team values. The issue is serious to the extent that Professor Edward Lawler wrote a recent post in Forbes magazine titled: Eliminating Performance Appraisals. In this post, prof. Edward questions whether organizations should stop doing performance appraisals altogether, because they “do more damage than good”, and “when poorly done, they create a multitude of problems”!

I felt I have a moral obligation to write something in this regard. My contribution in this post is a collection of resources and an attempt to structure the topic into three high level subtitles:

1. What's evil about performance appraisals
2. Should smarter people be rewarded more money (as a means of motivation)?
3. Using process data for the sake of individual performance

If you are a smart person suffering from a performance evaluation scheme from the middle ages, send your HR manager this post, and let him read the resources mentioned below. May be (I'm not sure) it may help.

1. What's evil about performance appraisals

First, this is an article: Should I Rank My Employees? from the Wall Street Journal. It mentions the following interesting survey:

"Stanford professors Jeffrey Pfeffer and Robert Sutton are among the most fervent critics. They cited a survey of more than 200 human resources professionals from companies employing more than 2,500 people that found that even the more than half the companies used forced ranking, the respondents 'reported that forced ranking resulted in lower productivity, inequity and skepticism, negative effects on employee engagement, reduced collaboration, and damage to morale and mistrust in leadership.' … "

Another blog by the famous software engineering management author: Esther Derby titled: Should a ScrumMaster (or any coach) Give Performance Appraisals? In this blog, Esther asks how would it be good while "psychologists know that 80 percent of people believe their performance is above average"

The topic of performance appraisal are very controversial to the extent that one of the so famous books in management in the last years is called: "Abolishing Performance Appraisals: Why They Backfire and What to Do Instead"

2. Should smarter people be rewarded more money (as a means of motivation)?

We need to change our believes that a merit system will not work unless it ranks employees into classes and every class is motivated by some more money.

This is a must-see master piece by RSA Animate: Drive: The surprising truth about what motivates us:

In this short animation, they attack very strongly the idea about motivation using financial incentives when it involves cognitive and knowledge work. At minute 1:50 till 4:15, this animation sites the results of a study done by three top universities in Engineering and Technology: MIT, University of Chicago, and Carnegie Mellon university:

"As long as the task involve only mechanical skill, bonuses worked as expected (higher pay = better performance). But, once the task called for rudimentary [basic or simple] cognitive skill, a larger reward led to poorer performance!"

Also, one of the most important books in software engineering history is Rapid Software Development: Taming Wild Software Schedules by Steve McConnell. This book was named the best Software engineering book in the year by Software Development magazine's Jolt Award. Please refer to this book to understand what motivates Software engineers. Chapter 11: Motivation is the best reference I read about motivating software engineers. In page 262, you'll find this quote: 

"At least two-dozen studies over the last 30 years have shown conclusively that people who expect to receive a reward for doing their jobs successfully don't perform as well as those who expect no reward at all (Kohn 1993). The work itself is the greatest motivator, and the more a manager stresses an external reward, the less interested the developer becomes in the work itself, and the more potential motivation is lost."

The author makes a very clear alarm that incentives has many forms which are non-monetary like:

• Dinners with company executives
• Vacation-time bonuses
• Gifts of appreciation (theater tickets or dinners for two)
• Sincere praise directed at a specific accomplishment
• Team T-shirts, polo shirts, rugby shirts, watches, pins, mugs, posters,
• Humorous or serious awards in the form of plaques, certificates, trophies, and the like
• Special events to celebrate significant accomplishments; depending on your team's preferences, and event might be a dinner at a favorite restaurant, a show, a trip, a ski day, or a dinner at the boss's house (or, for maximum effect, the boss's boss's house)
• Exceptions to company policies for the team, such as casual-dress Friday, a Ping-Pong table in your team's section of the building, free soda pop in the team refrigerator, and so on
• Special courses (outside the local area)
• Sponsorship at conferences that the organization would not ordinarily sponsor
• Grade-level promotions

You can download this book from this location.

One more article called One More Time: How Do You Motivate Employees?, which sold more than a million reprints making it the most popular article in the history of the Harvard Business Review. In this diagram, notice the particular position of the salary and it's weight as a demotivator rather than a motivator. 

Motivators and demotivators - Notice that salary (money) is not among the motivators, but rather a demotivator in case salary is not sufficient

Actually, what this diagram tells us is the same exact phrase mentioned in the RSA movie above at minute 4:50:

"If you don't pay enough, people won't be motivated. Pay people enough to take the issue of money off the table"

3. Using process data for the sake of individual performance

Forcing managers to use process data, like feature estimates, number of bugs, reported actual hours, etc. to evaluate team members will blow up the process metrics themselves. This, in turn, has a drastic effect on the process itself, making the team process-blind (not being able to improve the process based on process metrics) Being process-blind is the direct result of exploiting process metrics and reuse them as Targets, and as per Goodhart's law: "When a measure becomes a target, it ceases to be a good measure."

Why this happens? To understand the dynamics, let's recall the general rule put by Tim DeMorko, the author of the great book: Peopleware: Productive Projects and Teams's, a book which had an impact on the whole industry; the general rule is known as DeMarko's Principle:

"Effort moves towards whatever is measured"

This can happen subconsciously or even consciously; and this is considered one of the major pitfalls of measuring, as explained the this article: The seven pitfalls of performance measurement which considers: Risk of manipulation of performance data as one of them. When it comes to individual evaluation, use of process metrics becomes a real risk, and opportunity of manipulation is so widespread. Writers have been noting this again and again, to the extent that some writers like Eli Goldratt, the father of Theory of Constraints says:

"Tell me how you measure me, and I will tell you how I will behave!"

In summary, using process metrics to evaluate individuals distorts the metrics and after a while, the metrics lose their meaning and cease to reflect real process data.

A Final Word

Finally, I have to say that this topic is vast and needs a lot of effort to make a shift in the mindset of project and HR managers of software in Egypt. It is not easy, but impossible is not on my dictionary :)

Integrating Jenkins and ConQAT to Enable Continuous Clone Detection

One of the great features of ConQAT is its ability to detect code clones (duplicates). On the other hand, CI servers like Jenkins enables you to automatically check for code quality attributes. If we can merge both, this will become an invaluable tool for technical team leaders and will save them a lot of review effort.

Here is how you can do this:

Step 1: Define Your Policy of Preventing Code Clones

This is done by specifying the ConQat Run configuration files (.cqr) using eclipse. That is, create a cqr file which detects kinds of duplicates that you don't want to see in the code altogether.

For example, you may define a cqr file which detects exact code clones of length greater than 10 lines of code. This is a screen shot of a cqr file which does exactly this job:

ConQat Run conf file with parameters

Step 2: Invoke ConQAT cqr from Jenkins

Ant can do this using shell scripts or command lines, as follows:

cd  <ConQat Location>\conqat\binconqat -f <cqr file location>\JavaCloneAnalysis.cqr

 Note: Make sure that you specify the output directory in the configuration file appropriately, because Jenkins will be accessing it later in the next step

Step3: Introspect the clones.xml file, and fail the build if it has clones

Let Ant check the clones.xml file generated. This is an ant target that does this job, add it to your build.xml file:

<!--=========================================================================

Check the file named in the property file.to.check (the clons.xml file) to see

if there are any clones.

The way this works is to find all lines containing the text "cloneClass" and put them into a separate file.  Then it checks to see if this file has non-zero length. If so, then there are errors, and it sets the property clones.found. Then it calls the fail-if-clones-found target, which doesn't execute if the clones.found property isn't set.

-->

<target name="check-clones-file"

        description="Checks the file (specified in ${file.to.check}) for clones">

       <property name="file.to.check" description="The file to hold the clones" />

       <copy file="${file.to.check}" tofile="${file.clonecount}">

              <filterchain>

                     <linecontains>

                           <contains value="cloneClass" />

                     </linecontains>

              </filterchain>

       </copy>

       <condition property="clones.found" value="true">

              <length file="${file.clonecount}" when="gt" length="0" />

       </condition>

       <antcall target="fail-if-clones-found" />

</target>

<!-- Fail the build if clones detected-->

<target name="fail-if-clones-found" if="clones.found">

       <echo message="Code clones found - setting build fail flag..." />

       <fail message="Code clones detected during ${codeline} build.  Check logs." />

</target>

<!-- ================================================================== -->

Note: In order to pass parameters to the ant script, click on the advanced button and add parameters as in the following screen:

Passing parameters to Ant

Becoming a Technical Team Leader (TTL)

2003 I was appointed a senior position at IBM and became a technical team leader. This appointment was based on two things. First, I have spent 3 years in development. Second, I was an excellent developer! Are these enough criteria to become a technical team leader? I've already experienced the answer myself. I have led the team the worst way one could imagine!

Since then, I have been thinking about this topic, and read the excellent book of Gerald Weinberg, Becoming a Technical Leader. After years and years of leading technical teams, the idea became very clear in my mind about what it is like to be a technical team leader; what's expected from you, what's your necessary qualifications and what's you main responsibilities?

This is an attempt to answer this question:

Technical Leadership Core Responsibilities

A Technical Team Leader (TTL) should demonstrate capability in three main areas:

First and most important: Team Support. He can motivate the team, he has the ability and art of facilitating team activities, and he can organize team work into a process oriented manner. 

Second, a TTL is responsible of nurturing/enforcing and monitoring the product technical excellence and high quality. More specifically, the TTL is not responsible of doing this, but he is responsible of making sure this is realized by the whole team. To be more clear, if the TTL has developed an excellent product by himself while the team is doing nothing, then he is still failing in this regard. 

Finally, a TTL should sponsor innovation in the team. This is different from technical excellence. It is related to the team spirit and desire to experiment and try new things and unconventional solutions. This is different for problem solving, because you can solve a problem in a dumb way! What the team needs here is someone to sponsor the activity whenever it is needed and make sure a problem is solved in an innovative, not dumb, way.

In all of these responsibilities, there is a common component of organization. The TTL is responsible to organize accumulated knowledge and information gained by the team, and make it available and easy to find and use when necessary by any team member. Also, organizing the team process, which is a responsibility which may take a lot of time and effort to monitor and foster.

If you are going to become a TTL, make sure you get enough knowledge about these topics above. It is your responsibility to become knowledgeable, or else you will spend years or fumbling in the darkness and learn by trial and error!

Back From South Africa! Successful talk and Excellent Workshop

 Two weeks ago, I was invited to deliver a talk and a workshop at AgileAfrica 2014. In fact, this year's edition of the conference is amazing. It is very well organized, the venue is great, and most important, the content of the conference was very well selected.

Joburg from the conference hotel roof. A place full of life!

How to Fail with Agile

My talk was about How to Fail with Agile. Several years ago, I have written an article about this topic at Scrum Alliance, which listed some failure patterns in agile practice adoption. But, after more years of experience, I have designed this talk into two parts:

• Failure to adopt the agile mindset: Successful agile transformation requires a mind-shift from traditional/fixed mentality to responsive/adaptive mentality. This is why I say that agile adoption is a transformation project of persons, not processes, tools, or customers! If persons fail to change the way they think about software development, it is likely they'll fail to apply scrum, use tools, or convince their customers to be more collaborative.
• Failure to adopt some agile practices: Even if people are succeeding in adopting the adaptive and agile mentality, they may still fail in adopting practices. The main reason in my opinion is that the team does not grasp the value of practices. The second reason is implementing one practice while it will never succeed except with another practice. I called this twin practices. 

Sustainable Legacy Code Refactoring Workshop

I have also conducted a one-day refactoring workshop, which I used to deliver in Egypt for many years now. However, in South Africa, I have introduced several changes to the way the workshop is delivered. This, in my opinion, was a turning point in the workshop effectiveness!

In this edition of the workshop, I tried to resolve many issues faced  in previous rounds. For example, issues with tools setup, being overwhelmed with the too many questions and issues faced by trainees, unable to track the progress of individuals doing the exercises; sometimes, I completely lost several attendees who check out from the exercise due to issues they face.

These are some of the ideas I tried:

Working in pairs was a great enabler. Even if you are a genius, you will need someone to remind you with a missing semicolon or an open bracket!

A task board for every pair, in which they show their progress with the workshop exercises. This gave me visibility of progress and problems, and enabled me adjust the pace accordingly.

On-Wall Reference. A technique that I used to help the trainees. They can instantly get help about possible refactorings that they may apply to work with exercises. 

I have also introduced several key enhancements in the workshop, like writing detailed step-by-step guidelines, adding breaks in which I explain key concepts in between exercises, working in iterations, and some other enhancements in the training content.

Here are some of the written feedback which I received from the workshop attendees:

• A very enlightening workshop! The importance of refactoring code was greatly realized during this workshop 
• A very informative workshop. Very useful. Will try to incorporate the lessons learned 
• Great workshop. would be advantageous if it was spread out to two days. This would allow people to put to practice the tools and material learn. We then could see how we’ve absorbed the material better. 
• Helpful workshop. Fully appreciated the importance of code refactoring techniques 
• Very instructive course. I have learned how to refactor a code using modern tools than manual refactoring.
• Awesome workshop. Thanks Amr !!

Actually, it was amazing to receive all this positive feedback al7amdulillah (thanks for Allah). Soon inshaAllah, I will plan several other public rounds in Egypt and the Middle East. 

What Makes Maintenance Goes Awry?

An excellent analysis of the maintenance profession in Dennis Smith's book: Designing Maintainable Software. According to Dennis, the profession of maintenance makes programmers working on maintenance feel that they are inferior to their colleagues working on new development, and they are generally perceived to be less competent and doing less important job in the software team in general. According to Dennis, this positively complicates code because this process selects the most junior and least competent programmer to maintain code in an unprofessional and improper way, which makes code become poor, if not already very poor:

Here is a book excerpt on page 8 describing the problem:

"Careers in programming typically begin by maintaining computer software . Maintenance is considered a relatively harmless activity where entry level programmers can become proficient in the craft (Gorla 91; Rombach 91)"

This, in my opinion is the basic assumption, which makes things go awry with maintenance, which is maintenance is relatively easy and does not need experienced programmers to perform.

"While in maintenance, programmers are expected to obtain a thorough understanding of the department's software conventions, the idiosyncrasies of computer equipment, and the company's culture and methods of operation. Programmers in maintenance are aware that they are at the bottom of the professional hierarchy and look forward to leaving their present assignment. Maintainers demonstrating superior ability advance into more creative positions, such as development programmer, systems analyst, or information specialist. Other's migrate to different positions within the company, or gain employment in another concern where rewards and opportunity for professional growth are more promising. The rest have maintenance as a career."

Then, he says the result of this approach:

"That leaves the task of keeping software properly functioning to programmers who are poorly motivated, have low esteem, and possess marginal skills (Glass & Noiseaux 81)"

This is an excellent articulation of one of the problems that we face in this profession. There are other major differences which he lists among comparing working for maintenance or new development:

1. Maintainers usually work individually while new development work in teams
2. There are almost no planning which takes place. This opens the door for a lot of up's and down's in the maintainer's work. This in practice creates a non-sustainable career.
3. Maintainers usually does other tasks which are marginal an even less important than programming (in their opinion) so that to fill the gaps in their free time. 

How Kanban Works

This is the title of my first article on infoq.com: How Kanban Works, published on July 31st 2014. In this article, I have tried to explain using examples and case studies how (or why) kanban works in software development.

Have a look at it and let me know your opinion.

Detect Code Duplicates Using ConQAT

Finally, I had sometime to do this simple and invaluable tutorial on your first steps with ConQAT to detect code clones.

• Open eclipse with conqat enabled
• From the file menu - New - Other - ConQAT - Run Config:

•  Select a parent project to create the conqat config. This may be any project or folder, even an empty project. 

• Fill the missing parameters, then click the launch config link as in the next screen shot: 

• After the run completes, and xml file containing all the clones are generated in the output folder. To view the clones, , goto clone detection - open clone file. 

• Here you are:

• Don't forget to open the clones perspective. This will help you visualize the clones.

Diagrams of Effects

Diagrams of Effects were first introduced in the famous four-volume series: Quality Software Management by Gerald Weinberg. It is a great enabler when trying to understand the dynamics of a system exhibiting non-linear behavior, very similar to software development team systems.

Diagrams of Effects are similar to Causal Loop Diagrams (CLD), but it is slightly different in notation and is more powerful in modeling human interventions in the system. A diagram of effects consists primarily of nodes and arrows. Each node corresponds to a measurable quantity. Easy arrow corresponds to an effect (whether positive or negative) which the source node exhibit on the target node. This is a description of the diagram elements:

Element	Notation	Description
Node		A measured quantity. It can be actual measurement, or deduced from observation or by experience
Cloud Node		A measurable quantity, although actual measurement may not be done. Or, it may represent a conceptual measurement (like stress, pressure, etc.) which may be too expensive to measure, or just not worth the trouble.
Natural Positive Effect		If A moves in one direction, B moves in the same direction. This effect is natural (without human intervention)
Natural Negative Effect		If A moves in one direction, B moves in the opposite direction. This effect is natural (without human intervention)
Positive Human Intervention		Indicates a human intervention which makes the affected measurement move in the same direction as the movement of the cause.
Negative Human Intervention		Indicates a human intervention which makes the affected measurement move in the opposite direction as the movement of the cause.
Human intervention with open choice of Effect		Indicates a human intervention which makes the affected measurement move either in the same direction or the opposite direction, depending on the intervention.

Reinforcing & Balancing Loops:

What is interesting about Diagrams of Effects is that they reveal Reinforcing loops and Balancing loops. Reinforcing loops are cycles of effects which reinforce each other and may drive the system to failure. In the following example, more bugs lead to higher levels of stress which leads to more bugs. Also, it works in the other way as well, less bugs leads to less stress which leads to less bugs:

Another type of feedback loops is the Balancing loop, in which one effect balances another. In the following example, in case bugs increase, team exerts more effort in code review which leads to less bugs, which balances the effect of increasing bugs:

Such dynamic is not possible to be studied using  2-dimentional graphs. This is why Diagrams of Effects is an excellent tool for analyzing complex systems.

Why change? Is your team aware of the value?

As change agents, we introduce changes in organizations we work for. Sometimes, these changes are integrated smoothly into the way the team works. In other cases, we find a lot of friction and resistance.

One of the things which facilitates change and alleviates friction is explaining the value of change for your team. Although this seems straight forward, but we usually do not exert enough effort to do that!

In one case, I didn't need to explain the value of change, although the change looked so naive and has no value. See what happened when I asked a crowd of 220 audience to change places, and they just did it with no single objection!!

This was part of my keynote last August at AgileAfrica 2013. I understand why would someone just follow a keynote speaker telling him to do something even he/she didn't know its value. If I were sitting at their place I would most probably think that there is value, and I would rather wait till I see it later on. 

I have done this experiment with smaller groups. The result was completely the opposite. They challenged this request (to change places). They felt skeptical about the value of this change. It was necessary to convince then with the value of change before they do it. 

Take care when you are leading change in organizations: In order to take the organization one step forward, you would better explain the value of change for the whole organization, or at least for the whole stakeholders who are affected by this change. 

Useful Statistics about Maintainability

Here are some useful statistics collected from several papers:

Concise and Consistent Naming:

• Approximately, 70% of software programs are identifiers. Therefore, identifiers names are of paramount importance for readability

Unused Features: From this paper:

• Jim Johnson (the Standish Group) in his keynote at XP2012 reports that 45% of the features in the analyzed systems were never used
• Industrial business information system showed that 28% of its features were never used
• 25% of all method genealogies were never used

Code Clones and defects: Some very useful statistics from this paper: Do code clones matter?:

• 52% of code clones are inconsistent
• of these inconsistencies, 28% are introduced unintentionally, and 18% are faults in the system
• Overall, 10% of code clones are defective

Architectural documentation & decay:

• 9%-19% conformance of implementation to architecture, 72%-90% of these non-conformances are due to flaws in documentation
• 10%-28% decay in architecture

How much clones cost?

• 20% effort increase in maintenance due to code clones

Duplication in Model Elements

Interesting idea. If you are using Model-Driven development, how would you know that you have duplicates in your models? are you aware that this may be a source of many issues? If yes, are you aware that you have duplicates? If yes, are you doing anything about it?

I came across a paper talking about this: Clone Detection in Automotive Model-Based Development. The author has implemented an algorithm to detect clones in models. It is interesting that the results of the study shows that 37% of the model elements duplicated at least once!

Model clones highlighted in red and light blue

My Talk at Agile2013

After several months participating in Agile2013 with an experience report about refactoring legacy code, I find it very useful to write down things that I have learned, and my plans to benefit from this experience.

My talk at Nashville was very good al7amdulillah. the audience were very interested in the experiences that we've gone through. The first thing I've learned is that when you deliver a talk, you get better understanding about what you are talking about! There is a tradition which says: "المال تنقصه النفقة، والعلم يزكو بالإنفاق", or "expending money would decrease it, but expending knowledge would only increase it!"

The second thing I found is that teams really need a way out of the mazes of poor legacy code. I got two verbal and one written comment telling me that they are having so many problems with their code, and they felt that this roadmap of refactoring would be very applicable in their case. This was an indicator that I should continue working on more experiments and enhancing the roadmap more and more.

The results of the session evaluation was as follows:

Attendees: 50

• 40 green (would recommend to other)
• 6 yellow
• 4 red

I had some interesting written testimonials as well:

• "Amazing story of ingenuity and success! Excellent presentation"
• "Very interesting talk. It gives me hope we can tackle our own mountain"
• "Very good. Learned something we can apply"

One of the attendees gave me an interesting note that she missed half of the talk because of my english accent. This was an excellent feedback. In later sessions, I made a disclaimer that I'm talking "Egyptian English", which is similar to English but you need to concentrate more to translate as you hear :)

Another note is that data makes a difference with some audience. It just ticks with them when they see data. In a later talk about process increments, I got similar notes from other attendees. What I felt is that there are some types of attendees whom they start believe in what you say once they see some data!

Next Steps:

1. I should continue the ongoing experiments and collect more data to correlate refactoring with business metrics to indicate real return on investment
2. Conduct more experiments to collect more data. 
3. Package the roadmap (along with rules or the game, the guidelines, tips and tricks, notes about tools), and give it a name.
4. Enhance the tools, really don't know how, but I'm sure this will emerge in time. 

For your reference. This is the PowerPoint presentation of my talk, and this is the full published paper.

Trying to Understand Why Kanban Works

Recently, I came across a book chapter explaining Little's Law; published by Massachusetts Institute of Technology. This chapter is an excellent read which is simple and yet digs into the heart of Little's Law. Reading about queuing theory is provocative and makes me relate many of the already established ideas to Lean software and Kanban.

One of the issues which I found this book chapter explaining very well is the difference between Little's law in its original formulation (which considers the Arrival Rate as one of the formula parameters) and its application in manufacturing systems (which replaces arrival rate with throughput). Here is an explanation:

Little’s Law

Little's Law state that:

L = λ W

where

L = average number of items in the queueing system
λ = arrival rate of new items to the system
W = average wait time for an item in the system

John Little argues that this law is robust and generic and holds exactly to any queuing system given an essential condition; which is "to have a finite window of observation that starts [when the system is empty] and stops when the system is empty" (p.88). Moreover, Little provides a mathematical proof for the law along with many applications in reality.

Little’s Law in Software Systems

Let's jump into software and map these concepts to Kanban. In Kanban, this is how Little's Law is stated:

WIP = Th * CT

where

WIP (average Work In Process) = average amount of unfinished items (bugs, user stories, change requests, etc.) in the development system
Th (Throughput) = Team output in unit of time
CT (Cycle Time) = Average time it takes the team to finish one item

Two basic differences between the two formulas: The first one talks about input or arrival rate, whereas the latter talks about output rate or throughput. The second issue is the condition which Little stated: that the system should start with 0 items and end at 0 items. In software, we rarely witness a system which has no maintenance requests.

To resolve these differences, Little indicated a more subtle condition of the Law to hold, which is no items to go inside the system and get lost or do not get finished, which he calls “conservation of flow” (p. 93). If we apply this condition to the system, we can easily show that the input rate = output rate, and therefore, we can relate Lambda (λ) with throughout (th).

For the second condition (system should start and end in 0 items), Little argues that the law “still applies, at least as an approximation, as long as we select a time interval that is long enough”. (p. 93)

What’s useful about this Law?
Little’s Law is a very powerful tool to use for managers. If we have two parts, and we can instantly calculate the third.

Increase team throughput

If your capabilities are fixed and want to increase throughput, the only solution is to increase WIP, and increase the team size. If this is not doable, and your input rate is high and getting higher, you may decide to decrease the cycle time instead of increasing the WIP and this may involve automating the deployment process.

Stabilize Cycle time

If you are struggling to stabilize the process so that to meet some SLA, Little’s Law gives insight about what to change in the system. You may either increase/decrease with WIP or empower your team to meet a specific SLA.

Study behavior of specific request types
Little’s Law works for a sample of item in the system as well. You may zoom into the items in the system and study the dynamics of a specific segment (like high severity bugs, for instance).

Interesting quotes

Quotes that deeply influenced how I think!

“I hear, and I forget
I see, and I remember
I do, and I understand”
-- Ancient Chinese Proverb

“Leadership is the process of creating an environment in which people become empowered”
-- Gerald M. Weinberg

"When projects fail, it's rarely technical"
-- Jim Johnson, the Standish Group

Parkinson’s Law:
“Work expands so that to fill the time available for its completion"

"An approximate answer to the right problem is worth a great deal more time than a precise answer to the wrong problem" 

-- John W. Tukey

“Insanity is doing the same thing, over and over again, but expecting different results.”
-- Albert Einstein

“Two things are infinite: the universe and human stupidity; and I'm not sure about the universe.”
-- Albert Einstein

“If you can't explain it to a six year old, you don't understand it yourself.”
-- Albert Einstein

“Anyone who has never made a mistake has never tried anything new.”
-- Albert Einstein

“A clever person solves a problem. A wise person avoids it.”
-- Albert Einstein

“Everything must be made as simple as possible. But not simpler.”
-- Albert Einstein

“Failure at an organizational level seems to come  from the inability to customize processes and  make them their own. Trying to apply someone  else’s template to your organization directly  doesn’t work well. It leaves out too many  important details of the previous successes and  ignores your company’s specific situation. ”
-- Kent Beck Extreme Programming founder in a 2006 interview with InfoQ.com

"Nothing in this world was so powerful as an idea whose time has come"
-- Victor Hugo

"He who is good with a hammer thinks everything is a nail"
-- Maslow

"It seems that perfection is attained, not when there is nothing more to add, but when there is nothing more to take away."
-- Antoine de Saint-Exupery

"Leadership is the process of creating an environment in which people become empowered"
-- Gerald M. Weinberg

"We are being ruined by the best efforts of people who are doing the wrong thing."
-- Edward Demming

Redmine Arabic

A while ago, I worked with a client who is using Redmine Arabic interface. I found the arabic translation of Redmine very weak. It is missing many translations and miss-translates many others and causes a lot of confusion.

The good news is that I have reviewed Redmine arabization and adjusted the arabic translation to match the majority of arabic speakers in Egypt, the gulf area, and the Middle East. Also, I have fixed many incorrect translations and added missing ones.

The new translation is released with Redmine 2.4.0, and here is the patch that I have submitted.