sebinsua.com

RESTful Web Services correctly inherit and use HTTP as their interface

There’s been a lot of buzz on RESTful Web Services [1] and yet there are still far too many developers that believe they may implement it by simply using a Rest class provided by their favourite framework.

I wonder if this has been helped by the obtuse or long-winded articles that are out there on the web and so here is my attempt at explaining the concept as concisely as possible:

Building a RESTful web service requires that you (a) make your API stateless to help cacheability. And also requires that you stop building the same concepts that already exist in HTTP as part of your API and instead build a uniform API [2] that inherits the HTTP Interface [3] by (b) treating URLs as resources, (c) implementing CRUD using the HTTP methods POST, GET, PUT, and DELETE; and additionally using POST for operations with side-effects such as financial transactions, (d) using the HTTP response codes and header data correctly, and by (e) identifying and interconnecting resources by URIs in the responses, hence being hypertext-driven.

[1] http://roy.gbiv.com/untangled/tag/rest

[2] http://news.ycombinator.com/item?id=2796371

[3] http://www.ietf.org/rfc/rfc2616.txt

Empowerment

Groups often create feedback loops. At their worst they represent a mob that snuffs out any individual intelligence within. At their best they’re greater than the sum of their parts.

It has been shown that the collective intelligence held by a group is (a) positively affected by having a large number of socially-sensitive members whom are able to accurately read each other’s emotions, and (b) negatively affected by overbearing leaders that are reluctant to cede the floor to let others talk [1]. Groups which contain sensitive, participative members are intelligent, productive groups.

In many organisations if you privately ask somebody their opinion it does not match the opinion they give in public. For fear of ramifications many will act against even their most rational beliefs. Less sensitive individuals are more likely to be non-participative when they see that they will (1) need to defend themselves against overbearing members of a group, or (2) perceive their opinion as high risk in comparison to the group’s traditional value of security. On the other hand, more sensitive individuals are more capable of weighing the costs involved and participating.

Immediately, there are two concrete actions which if taken could help mitigate the first issue:

1. Formally delineate authority. Reduce the ability for members to misappropriate their authority – that is, power granted for x should not be used to make decisions on y.
2. Create a clear process for pushing and voting on change that is distinct from the group’s culture.

Unfortunately, the second issue is more significant and its solution requires a long-term shift to a more positive, innovative culture. In a company, I believe this has to be tackled on a personal level by acknowledging that we employ others for their talent and experience and that therefore we make better use of each other’s abilities when we give credence to their fresh opinions on old decisions. I assert that If you actively encourage employees to constructively challenge each other and to take ownership of their own ideas each individual employee will find it easier to participate and the collective intelligence of the group should increase.

As a manifesto:

Your responsibility is to encourage each other’s capacity to act independently. Your responsibility is to empower each to hold their own values and opinions with confidence. Your responsibility is to stand by them when they act decisively. Your responsibility is to trust them and their ideas. Your responsibility is to stop them when they say they are “still acclimatising”, act pessimistic or make light of feeling forced into unproductive work. Test uncertainty; don’t live life paralysed by doubt! Listening, understanding others, and being a cautious judge is wonderful but when you believe that something is right you should assert this with diplomacy and certitude, not simply for yourself but for those around you.

Put your faith in great people and let them know they are not alone. Through the empowerment of others create positive change.

[1] http://www.boston.com/bostonglobe/ideas/articles/2010/12/19/group_iq

Team Leadership

In order to motivate groups to take ownership, be creative and produce their best work, we must align individuals into a team vision [1].

In concrete actions

1. In a stand-up meeting every morning [2]:
   1. What did you do yesterday?
   2. What will you do today?
   3. Are there any impediments in your way?
2. In an email every few days:
   1. What tasks currently exist? Who is doing what?
   2. Show the fundamental directions the group is moving and give everybody a chance for input on this.
   3. Encouragement and celebration of group effort.
3. Make it easy for developers to brainstorm easily (for example, an IRC server). Whatever solution is arrived at, make sure it is obvious.

These abstract directions should also be pursued

1. Pave their path to self-actualization.
2. Give credit: attribute correctly.
3. Celebrate Team Effort: place names of people together for group cohesion.
4. In cases of low motivation, use peer pressure: give a developer an ultra-visible high priority; something all know is a home run. Email stakeholders and CC the developer explaining to everybody that this is their number one priority.

[1] http://liveingreatness.com

[2] http://www.mountaingoatsoftware.com/scrum/daily-scrum

Meaningful Communication

Take a look at the hundreds of emails you received today: how many of them are helpful? Have you ever been to a meeting without an agenda or in which 80% of the discussion wasn’t relevant to you? Emails and disturbances make people less intelligent than if they were smoking pot [1]. At any opportunity you have, take yourself and others out of this.

In concrete actions

1. Keep the number of stakeholders against each project to the minimum. Print the list of stakeholders out and pass it onto everybody on a project.
2. Face-to-face communication is more fruitful when communication is complex or one-off and needs to be actioned immediately.
3. Don’t write an email unless you are passing on new information.
4. Avoid To/CC’ing people into your emails unless the conversation you are creating is specifically related to them. There is only a certain amount they can read a day and too much disruption gives less time for real responsibilities.
5. Avoid using large email groups as they create far too much noise and produce only a small amount of benefit. Instead you should have smaller more organic email groups for specific projects.
6. Living information should be created by your processes: development, reporting bugs, meetings, and conversations. Ensure that writing code and sitting in meetings produces concrete information.
7. Information should be accessible. It should not only be stored in emails since these are ephemeral and get lost in time.

[1] http://articles.cnn.com/2005-04-22/world/text.iq_1_mails-iq-messages

Hiring Tech Talent

“Fast-growing companies at large scale do enormous amounts of college recruiting. That’s because the quality of the pool is much higher than the pool of out-of-work programmers… not because young people are smarter or better programmers but simply because the candidate pool includes a cross-section of skills, whereas the candidate pool of out-of-work programmers is biased to programmers who can’t find work.” [1]

Who should you employ?

It’s very important to get the best people possible to work for your company. There are two qualities that you should look for: character and ability. Experience and advice has shown me that often character is more important than ability [2]. Look for those that have a high internal locus of control and have taken ownership of their destiny as they will have passion and drive. It may not be possible to fully judge character in a technical interview but if you treat probation as a period of time to find out developer fit then you will have more time to do so. Always keep in mind: action reveals character; character is destiny.

The next most important quality is technical ability. In developers this is highly variable and in terms of quantity and quality of work a smart developer can often be 2x, 4x or 10x more productive than others while there are also people that are net-negative producing programmers (NNPP) who will cause irreparable problems with a codebase [3]. Hiring great programmers is better value so improving the hiring process will be very effective in improving the quality of your services.

In concrete actions

1. Use a service that will quantitatively rank developers’ code [4].
2. Hire developers from networks with high-entry barriers that can act as credentials: github/open-source projects, the elite graduate pool, stackoverflow, tech meetups, etc.
3. Don’t hire to fill short-term demands of extremely specific skills. If you hire smart people it will only takes a few months for them to become proficient at a new technology.
4. Don’t build a development team out of contractors. They are modern day mercenaries, solely motivated by money instead of a shared company vision. When times are good they cost you, but if times are bad often show no loyalty. Use them sparingly to scale with elastic demand.
5. Use the word of mouth of your best employees and healthily compensate them for this service.

How do you entice and keep employees?

The development employment market is very competitive and there are many reasons for it being difficult to attract the best employees [5]. A good first objective is to pass the famous ‘Joel Test’ [6].

The Joel Test

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

Other important motivations for developers [7]

1. Autonomy: Form a culture of “Freedom and Responsibility.” [8]
2. Mastery: Allow them to work on interesting technical problems [9].
3. Purpose: Create a company vision with high-impact projects to aspire to.
4. Compensation: Measure business value and compensate based on this.

[1] http://www.joelonsoftware.com/articles/FindingGreatDevelopers.html

[2] http://www.birdsnest.com/garcia.htm

[3] http://www.forbes.com/sites/venkateshrao/2011/12/05/the-rise-of-developeronomics

[4] http://codility.com/

[5] http://news.ycombinator.com/item?id=3357152

[6] http://www.joelonsoftware.com/articles/fog0000000043.html

[7] http://www.ted.com/talks/dan_pink_on_motivation.html

[8] http://practicalcloudcomputing.com/post/14040261889/netflix-linkedin

[9] http://cdixon.org/2011/12/29/recruiting-programmers-to-your-startup/

How To Drive Change

Finding the will to effect intent into action is difficult. The philosophy that works for me is: protracted belief, thought and action.

The best approaches to change are highly iterative and prolonged. You should act on what you believe, and you should believe in what you have substantiated with thought. If you are not in this for the long haul it’s unlikely you’ll ever be able to change anything.

Take a multi-pronged approach in which you prioritize and set goals first for yourself and then others. You cannot hope to instil anything into others that you can’t yourself. To paraphrase Dee Hock, ex-CEO of Visa, at any one point we are all leading and following yet when asked to think about what leadership is most mistakenly direct their thoughts to the leadership of subordinates. Instead, our most important responsibility is to: manage self, manage those that have authority over us, and manage our peers [1]. Managing subordinates should be of lesser importance because in an information economy they should be leading themselves.

Action is the final, most important step. It’s difficult because few have the courage to take responsibility for it and almost all look for validation from above when they should look within themselves. Lastly, I will leave you with a quote that I admire:

“Be heroic. You personally own the entire project. Do whatever it takes. Most projects have not only technical bottlenecks but political bottlenecks. Forget about the domain of the barriers or whether they are in your job description: overcome all barriers in your way; and be a friend and ally to everyone: shower all with your […] expertise.” [2]

[1] http://futurepositive.synearth.net/leader-follower/

[2] http://news.ycombinator.com/item?id=3340045

Passivity is the worst submission. →

Passivity is the worst submission because it is submission without individual intention to life itself.

Could a past socialite at school be at a disadvantage later on in life? →

Socializing too deeply early on at school is often a disadvantage in later life; the most successful people are those with strong raw talents that learnt to socialise out of school.

I also wrote this earlier this year. I had been reading too much John Holt.

Enhanced Autodidactism for the Chronically Lazy and Hyperactive. →

I wrote this earlier on in the year.  I also wrote a follow-up here; transaction analysis of human behaviour is ridiculously geeky but a very smart twist on time management.