Review of "Functional Principles for Object-Oriented Development"

After a long time of agility and philosophy, here's something technical for a change.

Previously...

Yesterday, I was talking OO and functional programming with Alex Chythlook, who told me that some problems I faced in Anathema could have been solved much easier applying functional programming idioms.

When I asked for details, he pointed me to a talk Jessica Kerr (@jessitron) held at GOTO 2014.

Go here in case you're watching the talk and would like to actually see the slides.

tl;dr:

All of her points are well made, and she's an entertaining presenter. I am happy that she pointed out some things that I didn't have names for previously.

However, I am surprised that many of these ideas are functional, as they just appear to be thorough applications of OO principles to me. If they have been functional all the time, then it is certainly good to call them thus.

What stood out

"Errors are data too" Jessica said and told us to "not interrupt the execution flow". 

I've long spoken out against checked exceptions, and this nails it: If I treat an error as data, I am forced to deal with it. Right now, just where I would process the good result. No handing the exception outward, no wrap-to-catch-later.

That way, Exceptions are limited to things that I, as a programmer, have not foreseen, and that's the way they are meant to be used.

Idempotence, something she touches on in the very end, is quite important, too. Good to have a word, now. It describes the idea that an executable block of code (so, a function or a Single Abstract Method object) should change the world only once, even if it's called multiple times.

From her talk, I picked up the notion that this should be true for every function, and I don't fully agree with that because complexity increases when I build things out of things that build things, even if those are just functions.

The third main takeaway was her call for Lazy Evaluation. Doing that forces you to think in Objects or First Order Functions, and prevents procedural style – and that should always be a good thing.

What appears to be OO

I first stumbled when Jessica introduced a service object to limit a function's access to the database. Isn't that an application of the interface segregation principle (ISP) and the Single Responsibility Principle (SRP)? 

Smalltalk people always told me that even in Java, the client should define the exposed interface, and this is just that: If I need a service that just inserts, the method should have access to only that.

Next, she speaks about specific typing - again, isn't that just OO? If something represents a name, I should call it "Name", not "String". The DDD people have said it since 2004 and hardly anyone listened, so Jeff Bay had to point it out again in his paper on Object Calisthenics some seven years ago, calling on us to "wrap all primitives and Strings" (and numeric objects, of course).

Applying this principle in classes and productive code, I can well say that it is a game changer - your code becomes much more clear and expressive this way, even more so when you apply his next rule – "use first order collections" - as well.

Back to Jessica: Good on her picking up on that, I fully agree. It surprised me, though, that she watered down the principle by us to Options and Tuples later on in her talk. Those two are never domain specific, so effectively, she just put two new primitive types on our plate. 

More recent languages have more elegant ways of expressing these concepts, and they might feel more at home there.

I was surprised once more when she presented the lack of concern about when or how my code is executed as a principle of functional programming. With the OO concept of encapsulation comes the idea of Single Abstract Method objects, which are handed around as executable blocks. She even pointed us to the GoF patterns Command and Strategy, so clearly, this has been around for a while and was considered OO back then. 

Did the GoF silently sneak in functional ideas? How dare they!

What I didn't quite get

Apart from these three good points, there was one I didn't get: Structural Sharing? What was it about, memory efficiency? Didn't she just tell us that we should rely on our compilers instead of doing their work?

Summary

So, all in all, it doesn't matter. Whether it's OO or functional, this is a good talk to watch. 

If you want to brush up on intermediate concepts of coding or see some examples of how things might get easier if you break your common patterns: Go watch!

Teams R SEXI

In this post, I will explore what makes a good Development Team in Scrum from an organizational perspective.

Great teams

When it comes to structuring the Development Team, the Scrum Guide tells us that the team is “cross-functional, with all of the skills as a team necessary to create a product increment” and that the team should be structured to “organize and manage their own work”. Finally, we learn that the team should have between 3 and 9 developers, to be able to contain all the skills required while not increasing management complexity beyond the level self-organization can casually deal with.

Over the past few years, I have helped some clients to improve their teams’ setup and structure, and found that there are more criteria that the Scrum Guide only hints at but never mentioned explicitly.

Have few dependencies

While Scrum expects the team to be able to provide the product increment on their own, corporate reality often sees products with a scope much larger than what a single team can produce in reasonable time.

You may have read about scaling approaches like LeSS, and their call for feature teams. Rare is the product, though, where splitting into features is possible the moment your start with Scrum.

To alleviate the situation, I look for a setup where inter-team dependencies are as few as possible. In an ideal case, this means that the team has one team to receive input from and one more team to deliver output to.

For work to flow, the team has to be independent from other teams. Define your teams so that their scope covers a large, uninterrupted piece of the value chain, and integrate technical concerns as much as possible.

That way, you will reduce the number of handovers both in planning and in the actual work done.

Stay together

In a corporate environment, projects start and stop all the time. Project managers vie for resources, eyes on the deadline, not on the social effects. For team members, this means that today’s colleague may be gone tomorrow – so each of them looks out for their own piece of work first and foremost.

When introducing Scrum in such an environment, I emphasize the twin values of stability and reliability.

It takes a stable environment for employees to benefit from investing in the team’s success rather than their own achievements. Team members learn to trust each other over time and start to co-operate. In a stable teams, members can learn each other’s abilities and preferences – and that’s what it takes to get better.

Reliability, meanwhile, means that team members are on the team, period. Splitting people between projects eats up time beyond the numbers in your spreadsheet, as it introduces interruptions in the form of urgent requests from outside projects.

Now, any corporation worth the name will have a complex resource distribution in place already, and you will be hard pressed to change it all at once. What to do?

Allot people to the product as much as possible, and encourage them to block fixed slots of time for working on the product. If necessary, suggest they turn off phones, chat and mail clients; empower them to postpone dealing with incoming requests till team time is over.

That way, their team can learn rely on them, and teamwork improves.

Learn from each other

Remember what the Scrum Guide said? “Teams organize and manage their own work.”

It takes a certain level of experience to do that, and I have frequently heard managers or Scrum Masters complain that their team is not yet ready for this level of freedom – and next coordinate the work themselves, trampling the sprouts of self-organization.

So, it takes experience for the team to self-organize, and it takes laissez-faire.

The best teams I worked with did not consist of veterans only, though, since less experienced team members bring two crucial factors to the team: By embracing their curiosity, they challenge long-standing practices; by working with several of their more senior colleagues, they foster communication.

So, when building a team, I look for a good mix of old hands and new to make learning happen and self-organization possible, while still having all the skills to actually build the product.

Make work flow

This concludes my thoughts about criteria to watch out for when building great teams:

reliabilty, stability, experience, cross-functionality and independence.

So, when you are next thinking about how to improve your team, just think “Teams R SEXI”, and you are well on your way:

Reliable

Stable

Experienced adequately

X-functional and

Independent

Mind, though, that these criteria are strongly skewed towards the organizational perspective and pay no heed to the more mushy, social criteria that are well worth considering as well.

What criteria do you apply to find your teams? Did you go at it from an entirely different angle? 

I am looking forward to your comments.

Focus and focus time

In this post, I explore the Scrum value of focus, the notion of focus time and its implications for your Scrum team’s setup.

Focus as a Scrum value

Focus. It is one of the core values of Scrum, reminding us to be precise about our development goals and to stay on target at all times.

Focus tells Product Owners to build one product for a well defined audience, tells Scrum Masters to help their teams improve in one area at a time, and tells the Development Team to go for the Sprint goal and only the Sprint goal.

It is them - the team - I want to focus on in this post, although the thoughts apply to the other roles as well.

Focus time

Recently, a client introduced me to the notion of focus time. By his definition, focus time is the part of a Sprint that the team actually spends working on product backlog items directly contributing to the Sprint goal.

Thus, focus time is comprised of all the work required to get one specific product backlog item from “ready” to “done”, including design, implementation, testing, documentation and posing the odd question to the Product Owner or relevant stakeholders.

It is not: Helping to prepare the next Sprint, demonstrating the product increment in the review, improving the process in the retrospective or organizing the team in the Daily Scrum.¹ While all of these activities are important, they are by definition off-focus, as they do not directly improve the product².

Perfect world

In an ideal setup, the team spends most of their time focused. The Scrum Guide allows for up to 10% of the development team’s time to be taken for product backlog refinement³, while planning, review and retrospective take up 10% of the team’s time yet again.

Another 5% are eaten up by Daily Scrums and general communication with people in- and outside of our product: Even the best of bosses and stakeholders need some attention from time to time.

This leaves our ideal development team with
100% Sprint time

- 10% refinement

- 10% planning, review, retrospective

- 5% Daily Scrum and communication

=  75% focus time

That’s 7½ workdays out of your two week sprint! Contrast that with the common complaint that Scrum is all talking and keeps people from getting things done.

Half measures

Rare, however, is the team where all team member contribute all day, every day. The larger an organization, the larger its tendency to split people’s time and attention over several projects or products.

25 years ago, in 'Quality Software Management: Systems Thinking', Gerald Weinberg introduced us to the hidden cost of context switching, claiming that an even split across two projects left a knowledge worker with only 40% of his or her capacity to apply to each of them. (While Weinberg's original text is not available for free, his idea has spread beyond the cover of his book.)

So, let’s split some people and look at their focus time:

50% allotted time

- 10% context switching

- 5% refinement

- 10% planning, review and retrospective

-  5% Daily Scrum and communication

= 20% focus time

In case you’re wondering, I left the numbers for the four main Scrum rituals at their original value since all teams I have worked with so far insisted that their split members take part in all of them, since this is where the team makes all major decisions.

So, out of a promised 50% of somebody’s time and attention, only 20% contribute directly to the goals we set for the product – that’s hardly more than half of the 37.5% we might expect when looking at the original calculation.

Now, suddenly, Scrum is all talk and no action.

Said and done

So, the idea of focus – concentrating on what we ought to do – lead us to the notion of focus time, the time spent directly contributing to the Sprint goal. We have seen that ¾ of a team’s time could be spent focused, and that this number shrinks drastically when we split people’s time across products.

Now, I’d like to invite you to examine the time your team spends focused.

Do you get close to ideal numbers? Are you in the 20% range, even though everyone is on the project 100% of their time? Where does the time people don’t spend focused go and which of these activities are really necessary?

All in all: What could you do to improve the numbers?

Besides looking at things that distract the team, you might want to look at the product backlog items your team and Product Owner agree upon for the sprint. Is there a common theme, so that most or all of them contribute to a single goal?

If they have little in common, one could argue, there is not really one Sprint goal, and the team could never reach the lofty numbers I laid out above. However, there could be leverage in the way the Product Owner prioritizes the product backlog or the way you plan your sprints.

Let’s talk about your numbers and your findings in the comments!

Postscriptum

Writing this post brought to my mind a number of questions, among them:

“What keeps teams from focussing and how to get back there quickly?”, “How to show the value of Scrum’s rituals to the ‘rather do than talk’ faction?”, and “Is focus time a good measure for the quality of a Scrum process? What other metrics are there?”

Comment below if you have thoughts on any of these questions or are particularly interested in one of them.

---

1 Neither is it taking part in communities of practice, performance reviews, answering mails, general discussion or undirected learning, along with most other things team members like to do.^↩

2 Actually, this is the main reason that some developers tend to resent them. Hackers want to do, not talk. As a Scrum Master, you could do worse than to think about this before your colleagues bring it up.^↩

3 Note that this is not the established practice of a “refinement meeting”, but rather includes all activities dealing with the process of refining the product backlog.^↩

Body scanner estimation

9 out of 10 coaches agree: Estimating is not about the numbers, but about the dialogue.

Even though, many teams find themselves discussing a meager difference in story points - often to the point of frustrated sighs - while the technical details are long clarified.

Today, I have been listening to an explanation of story point estimation. The team was just discussing a list of criteria to judge stories by, and I couldn't help but think: "What if we just cut to the dialogue instead of dealing with points, and used the criteria to encourage it?"

That thought led to a quasi-algorithmic way of estimating, quickly dubbed "Body scanner estimation" by my colleague Ilja Preuß (@ipreuss on twitter).

How to play

1. Discussing the story itself, and answer any questions.
2. Answer all of the following questions with either Yes or No.

• Inside/Outside
• Do we need to pull support or input from outside the team?
• Does it affect outside systems?
• Do we need to share knowledge about the results?
• Does it need management approval?
• Knowledge/Skill
• Does it need specialized knowledge? (Or can any of us do it?)
• Is this story the first of its kind for our team?
• Is it very time consuming?
• Is it annoying to complete?
• Technical
• Do we have technical debt in the vincinity?
• Does the change ripple throughout our system?
• Do we need to set up testing infrastructure?
• Do we need to set up build infrastructure?

3. Now, count the number of "Yes" and add 1 as the base cost.

4. Round the result to the nearest number from Fibonacci's sequence to get your estimation.

5. Sanity check the result.

This method of estimation gives teams a handrail to work with, with questions to spark further thought and discussion.

I yet to try Body scanner estimation, so I am eager to hear of your results. Do the questions make sense to you? Did you add some of your own?

More importantly, though, did you come up with a fresh way of estimating lately? 

Let us know in the comments.

A template to communicate intent

In a corporate environment, teams face many different stakeholders.

Despite of best efforts, team members often have trouble judging requests for what they are actually worth, and tend to react to apparent urgency instead of actual value.

A team lead I recently met found himself in the very same situation, and prompted me for advice. In our conversation, we found out that in his particular case, the issue was partly about communication: the team members didn't know the teams goals, and so they had little to go against.

However, knowing that goal would only get them so far, because things are rarely cut clearly - a request may be out of scope for the team, but fully aligned with the division goal.

The template

Shortly after, I came up with a template to cover three levels of goals and intent:

We will [achieve the team goal],
in order to [achieve the division's goal]
so that the company can [achieve the company's goal].

For example:
"We will ensure the performance of the mainframe
in order to enable the free flow of data
so that Skynet always remains one step ahead of the resistance."

How to apply it

Facing fresh input, this enables team members to think on their feet and look beyond the team's immediate goals, judging issues not only by what their team lead told them, but also by the larger objectives.

This mirrors the military concept of commander's intent, where doctrine says that the aim, purpose and implications of an operation have to be understood two echelons down - something that can hardly be achieved in a single sentence.

By that measure, just filling in the blanks makes for a nice poster, but leaves half the work undone: The actual act of face-to-face communication, where the team lead informs his colleagues about the three levels and their implications - once to make them clear, and once again whenever they change.

Obviously, a dialogue like this requires knowledge of the higher level's intent - but that is hardly a bad thing, since communication goals in a clear and concise fashion is part of proper leadership.

By my assessment, this template works best when the team has an overarching goal or mission that keeps constant for at least some weeks. With small adjustments, though, you could easily use the template for short term objectives like Sprint goals in a Scrum process.

What do you think of the template? What do you do to communicate management intent to your teams? Please tell me in the comments.

I like Java 8 streams

I'm learning the JDK 8 API.
This seems pretty sweet, for Java standards:

Stream<String> input = Stream.of("Tick", "Trick", "Track");
Map output = input.collect(toMap(t -> t.length(), t -> t, (t, t2) -> t + "," + t2));
System.out.println(output);

Result: {4=Tick, 5=Trick,Track}

Respite and Trust in Timeboxes

Looking for a proper translation for the concept of a "time-box" in the context of Scrum, I looked up the German word "Frist". The word describes a period of time in which a certain action may (or may not) be taken, it's mostly used in a judicial context.

Inspired by a note on the words roots in Old High German, I consulted Wiktionary, and discovered that the word has siblings in several Germanic languages and is known even in English (albeit obsolete).

I was delighted by the connotations on offer: Throughout the languages, the concept denotes not only an allowance of time, but also signals a respite or truce as well as trust - all of which are on display when mutually agreeing on a time-box in Scrum.

I couldn't wish for a better match.

A case against hierarchy

Re-reading Mastering the Art of War, I came across an excerpt from The Masters of Huainan:

In it, a lord asks his minister about the fate of another nation, and learns that it was destroyed through repeated victories in repeated wars. He voices his surprise, for victories are a good thing, thus prompting the minister to remind him:

"Where there are repeated wars, the people are weakened; when they score repeated victories, rulers become haughty. Let haughty rulers command weakened people, and rare is the nation that will not perish as a result."

Once again, there is striking similarity between the martial domain and that of business.
Think of a manager in a hierarchical organisation, successfully delivering project after project; yet without time for reflection and calibration.
Soon, he will rise to heroic status within his company and with growing responsibility grow estranged from those who work with him.

At the same time, his project teams won't have time to re-build their mind, their spirit and their tools - pressure is too high to take time for that, and slowly, they start to believe that there actually are more important things to do.
Over time, they will even come to believe in the manager's (and by extension, their own) invincibility.

They won't stand in for their needs, instead voicing their oppositon only among themselves - if at all, and even if they do, nobody will listen to those arguing against success.

With no one to correct or support him, the manager will fail at last, and - by definition - in his most important project yet.

In this, I see a strong point for eschewing hierarchy. Leadership should emerge ad-hoc, from the person, not the position. Thus, all are constantly reminded that everyone contributes equally to a shared success, that thinking, planning and action are parts of the same.
As a team, people grow together, fail together, learn together, with no room to grow haughty, to grow estranged or weak.

Did you see examples for this in your work? Did the contrary happen? How did you handle it?

One-Pagers: A tool to quickly summarize a topic

In 140 characters

One-pagers are a tool to quickly summarize any given topic, easily created in a group workshop.

In 200 words

A one-pager contains a tweetable summary, a concise description, a compilation of further reading and an an illustration of the topic.

Using the workshop format, all of this will exist after one hour:

Start up

1.  Take 5 minutes to explain the general process.

Create Tweets

Use Brain-Writing:

2.  Grab a sheet of paper each; put an extra one in the middle.

3.  For 3 minutes, write a tweetable text on the topic, exchange your sheet with the excess one. Repeat.
4.  In 3 more minutes, swap sheets and read through all of them.

5.  In 4 more minutes, agree on a single text or compile one.
6. Write it down on a fresh paper.

Create Details

7.  Grab a sheet of paper each.
8.  For 5 minutes, list bullet points for the various aspects of the topic.
9.  Hand your sheet to your neighbor.
10.  In 5 more minutes, select the entries you think are most valuable. The number to mark depends on the number of participants.
11.  In 5 more minutes, aggregate a list of most important points on a fresh sheet of paper. Add some front-matter text. Note some blog posts or books on the topic.

Illustrate

12.  Grab a sheet of paper each.
13.  In 10 minutes sketch an explanation of the topic.
14.  In 15 more minutes, look over each other’s drawings and select the best elements. Copy those elements on a fresh sheet or amend one of the existing pictures.

Wrap up

15.  In the 5 final minutes, hold a short presentation and wrap up the workshop.

Unlimited Info

• To learn, look for a One Page Universe-workshop near you
• For examples, see Fabian Schiller's "Agile Planet"
• For details, see Fabian Schiller's blog (German)

Illustrated

Final remarks

I learned about this technique in Martin Heider's workshop at play4agile 2014. Thanks, Martin!
The name "One-Pager" stems from the fact that you can pin all your results to a single sheet of A3 or flipchart paper.

Play to get a job

At many companies, job interviews are limited to a pretty single-sided meeting of talking heads:
The candidate is interviewed by several people from the employer-to-be, and struggles to present himself in a good light.

At play4agile 2014, a conference aiming to introduce playfulness to the workspace, we challenged that premise, wondering how make these get-togethers more bilateral - and less talk.

The first thought came quickly: Represent strengths by picking one out of a number of super-heroes, represent your weakness by picking a super-villain to match. To spur imagination, the organizers could bring a set of collectible cards representing the individual characters, so the less-geeky have a chance to be part of the ensuing conversation.
We iterated over a number of ideas on that pattern, but stuck with the issue of one-sidedness:
It always felt like the candidate was up for inspection, with the company and managers kept their secrets to themselves.
With questions like "How will you possibly fail us?" and "Why did you quit your last job?" up for discussion, we felt like few candidates were trusting enough to answer honestly.

An ice-breaker was called for, and we found in the form of physical games:
Something like the Columbian Hypnotist will speed things along greatly, allowing both the candidate and the organizers to let go of their preconceptions and find harmony in synchronized movement.

Afterwards, we focused on meeting the candidate on equal footing, with the company or one particular manager giving something of himself for everything that the candidate is asked to give.
Exploring his possible weaknesses as a team member? Offer your weakness as a leader first, and tell him how you are addressing that weakness right now.
Exploring issues with his last job? Be plain about issues at your company and how you are improving things.
To keep the spirit of playfulness, we enjoyed the thought of building this dialogue in Lego, forming a physical interface for the candidate to connect to.

Innovation Games are a great source of inspiration as well, with the "Product Box" a particular favourite of ours:
Ask candidates to build a box representing them to the team or company, while you build one for the respective containers.
This one not only offers points to talk about and greases your thoughts in an entertaining way, it also gives you a physical artifact you could use for a bi-lateral review some months in - possibly to amend it, and review it again at later point.

At the end of either exercise, you can ask the candidate to present the result to a camera for later discussion, giving him the option to take something home with him for later improvement (while keeping your treasured bricks).
The product boxes of successful hires might also make a great gallery for a team room or website!

How do you like these techniques? What are your favorite thoughts for lightening up an interview?
Please leave a comment!

Humility

This is the transcript of a lightning talk I gave at play4agile 2014, earlier this week:

"Today, I was talking to another practitioner, who remarked that there was a mark of excellence he had yet to experience in the workplace. I asked him about it, and he told me: Humility.

In that spirit, I would like to invite all of you, if the guy next to you is really quiet, to ask him to share his wisdom - because by this measure, he has all your problems already solved.

Thank you."

Hiring, two at a time

Lately, I've been thinking about good ways to find the right people to work with.
In other words, how to conduct job interviews so you get just the people you want.

In a timeless piece of advice, Dee Hock of Visa put it this way:

"Hire and promote first on the basis of integrity; second, motivation; third, capacity; fourth, understanding; fifth, knowledge; and last and least, experience.
“Without integrity, motivation is dangerous; without motivation, capacity is impotent; without capacity, understanding is limited; without understanding, knowledge is meaningless; without knowledge, experience is blind. Experience is easy to provide and quickly put to good use by people with all the other qualities.”

The authors of  "Tribal Leadership" translated that thought to looking for values and mindset first, because their research showed that only shared values and a common cause to strive for gave companies a culture that could overcome any challenge.

To me, a high focus on teamwork, collaboration and treating my colleagues as I would treat myself is part of those things, and so I found myself wondering about this:

Instead of interviewing (and subsequently, hiring) people one at a time, you could tell candidates to wait another moment, and only invite them when you have at least two people willing to join you - and could actually imagine to hire both.
Invite both of them and conduct an interview with both at the same time - and afterwards, give the room to them, with one single task: Writing a letter of advice about the qualities of the other guy and why to hire that person for your company.
Answer their questions and leave, observing them from outside, and meditate on whether you would hire none, one or both of them - but don't make a decision until you get their letters of recommendation and have observed them at work with what might well be their competitor.

I guess you could learn a lot from your observations in that hour - and if all goes well, you can hire two people who already know each other and have worked as a impromptu-team right on the spot, with demonstrated qualities in teamwork and in assessing another person's qualities.


What do you think of this?
Would it contribute to your hiring process?

Do you know of a company with interesting, successful procedures in hiring?
Please share.

Agile, 1300 A.D.

I currently read myself to sleep with "Three Kingdoms" by Lou Guanzhong (written ~1350 A.D), as translated by Moss Roberts.
There was an interesting segment yesterday which I'd like to share. In it, a learned man illustrates his prince's virtues - and comes close to things I would value today.
I'll try myself at a commentary in the traditional style.

Do you agree with my interpretation? Do you know of similar accounts in other ancient texts?

The Situation

China, 200 A.D.
It is a time of civil strife. Warlords from across the empire battle for supremacy.

Cao Cao, on of the main contenders, was made Regent and is the de-facto ruler of the empire, reducing the Emperor himself to little more than a figurehead.

Meanwhile, Yuan Shao, a northern warlord, is in open rebellion against the dynasty.

Amidst schemes and counter-schemes, both rulers try to rally troops and leaders to their side.

Eventually, Yuan Shao launches another campaign and Cao Cao finds himself outnumbered.

In this situation, Cao Cao turns to his chief strategist Guo Jia and asks him to evaluate the situation.
He receives a surprising account of lean management for an answer.

The Text

(The Text itself is in bold black, while my thoughts are plain grey.)

"I'd love to teach him a lesson," [Cao Cao] went on. "But do you think we're strong enough?"

Guo Jia replied, 

"[...]Now then, Yuan Shao has ten weak points and you have ten advantages. The size of his forces should not intimidate us.

The size of a force - military or commercial - does not matter. It is the quality of personnel that determines success, not the sheer amount. 

Consider. 

First, Yuan Shao governs with a profusion of rules and regulations; your order is simple and not constraining. Thus, you excel in principles of government.

Through excessive rules, Yuan Shao restricts his commanders' abilities. Even the best aide can not work properly when bureaucracy won't let him. By naming goals to reach, not ways to get there, the wise prince allows those below to think for themselves and judge the situation as it arises.

Second, Yuan Shao acts without legitimacy; you lead with the imperial sanction. Thus, your cause is true and honorable.

Legitimacy, and thus popular support. can be granted or earned. 

By his title and association with the (proper) imperial order, Cao Cao enjoys the people's support, whereas Yuan Shao has to first prove his worth to the common man and lesser leaders. 

Both the official bureaucracy and people around him are in favor of him who works in sync with the organization.

Third, since the reigns of [former emperors] Huan and Ling, court rule has suffered from  laxity and Yuan Shao, too, has the same habit; you require strict discipline. Thus, you excel in administration.

Through the excess of rules, it is hard to see where the leader's goals and the action taken align. If every rule counts, as in Cao Cao's case, things become simple: You either follow them harmoniously, or you don't.

Thus, less rules support stricter discipline, as misconduct becomes more evident and its impact more profound.

Fourth, Yuan Shao is ostensibly tolerant but inwardly envious and awards appointments mainly to his relatives; you are outwardly direct and inwardly understanding and employ men according to their ability. Thus, you excel in judgement.

If you want to work with the best, tolerate their quirks, but speak frankly if their behaviour and your goals get misaligned. Only if you do this, you can rely on and trust each other.

Fifth, Yuan Shao makes plans but rarely a decision; you formulate a plan and act on it. Thus, you excel in strategy.

Stop starting. Start finishing.

Sixth, Yuan Shao seeks only to enhance his reputation; you treat others with utter sincerity. Thus, you excel in morality.

In the end, you will be judged by your results. 

Only if words, actions and results match you can build a lasting reputation.

Seventh, Yuan Shao is solicitous of those close to him, indifferent to those farther away; you have an all-embracing concern. Thus, you excel in humanity.

By treating subordinates close to his command better than those in the field, Yuan Shao mis-rewards their action. 

To make decisions in a fair manner, you have weigh the interests of all your partners and clients, no matter how frequent the interaction.

Eighth, Yuan Shao is often misled by petty slander; you are impervious to gossip. Thus, you excel in discretion.

A wise leader learns to distinguish rumor and slander from actual concern, and acts accordingly.

Ninth, Yuan Shao does not distinguish right and wrong, you have rules and regulations that are strict and clear. Thus, you excel in civil administration.

Not only does he make up and excess of rules and let discipline slip, Yuan Shao is also unable to judge whether a broken rule was wrongly broken and requires punishment.

This illustrates the importance of proper administration once again: 

Only if rules are simple and few, it is possible to know them all.

Only if rules are simple and few, it is possible to see them broken.

Only if rules are simple and few, you can punish offenders without doubt.

Tenth, Yuan Shao is inclined to take empty stances but is ignorant of the essentials of warfare; you have won battles even when outnumbered, waging war with uncanny skill. Thus, you excel in arms.

Despite all of the other advantages, Cao Cao would not stand a chance if Yuan Shao had demonstrated his superiority before. A proven leader - with a proven team - is as important as are the other virtues, as experience and success yield greater legitimacy.

You will prevail over Yuan Shao by virtue of these ten points of excellence."

Cao Cao smiled appreciatively. "I don't think," he said, "I am adequate to live up to such a description."

Windows Setup, Summer 2012 edition

Sweet as it may be for casual users, I find Windows to be lacking when it comes to development.
Here are some tools that I find indispensible to work at full capacity.

Which do you like? Where am I missing out?

System Tools
MS SysInternals Suite Process Explorer: A fully featured replacement for the built in Task Manager, this one shows processes and their dependencies, system load and even file handles.

Rapid Environment Editor: As it stands, the "Environment Variables" section in Windows' control panel is both well hidden and a pain to use. Enter Rapid EE - it makes editing a breeze, has auto-completion for path-like values and even checks entries for validity.

Everyday Tools

Console2: Console is window dressing for Windows' command prompt. Tabs? Check. Colors? Check. Resizing? Check again. It even remembers where you want your prompt to start.
Notepad++: It's no secret that the original Notepad isn't quite up to standards. The two ++ in this tools name are just what I need.
Google Chrome: It's the world's most popular browser for a reason.
Pidgin: There are many IM clients out there. I just happen to like pidgin best.

Generic Developer Tools

Putty & WinSCP: There's hardly a day I don't use one of these. They do what they are built for, and they do it admirably.

MSysGit: Git for Windows. Of all the SCMs I have used, git feels best, and this Windows package answers all questions I might have.

Java Developer Tools

IntelliJ IDEA: I liked IDEA when I first saw its phenomenal Grails support. I started loving it when I first used it for Java development. I used eclipse for 7 years, but I never looked back.

JProfiler: Now that Java comes with a profiler of its own, JProfiler is no longer the indispensible tool it once was. Easy to use, simple to integrate and abundantly powerful, it is still the best to me.
Maven & Gradle: While I like Gradle better by far, it pays to have both of them around if you want to have a look at the inside of open source software once in a while.


Disclosure: I have received free Open Source licenses for both JProfiler and IntelliJ IDEA.