Tesler’s Law is this:

The Law of Conservation of Complexity: Every application must have an inherent amount of irreducible complexity. The only question is who will have to deal with it.

In the interview Bill de hOra links to, Tesler further enumerates on his law:

If a million users each waste a minute a day dealing with complexity that an engineer could have eliminated in a week by making the software a little more complex, you are penalizing the user to make the engineer’s job easier.

Whose time is more important to the success of your business? For mass market software, unless you have a sustainable monopoly position, the customer’s time has to be more important to you than your own.

I agree. I think if we look at some of the most successful applications in history, we’ll find Tesler’s law at work behind their success.

This post brought to you by Programmer's Paradox

The more Nerf wars that employees have is an indication they are happier. Why? It is a sign that people are being outgoing and embracing each other.

As Nerf wars become less frequent or stop all together, it is a sign that people are retreating into their shells and that collaboration has stopped. The health of the company is trending downward.

Of course, not every company is going to have Nerf wars, but replace Nerf wars with any generally outgoing activity a company might regularly and spontaneously engage in and the indicator should still hold.

This post brought to you by Programmer's Paradox

if __name__ == '__main__'
    unittest.main()

in your test file, like I did, you don’t think everything is working because none of the tests fail.

This post brought to you by Programmer's Paradox

The argument goes that open is good, because then everyone can communicate easier.  I agree that this is true, but at the same time it leads to easier distraction, leading to increased context switching and loss of productivity.  In this regard, I agree with Joel on the subject.  Does the increased communication offset the lose of productivity due to context switching?  I would argue no.  Even Bob Martin, a signer of the Agile Manifesto, while he advocates for an open setting, qualifies his advocacy by saying that developers also need a quiet place to retreat to to complete work without distraction.

Science backs up the fact that as humans, we need privacy to work effectively.  Recently I came across this article: Tough Choices: How Making Decisions Tires Your Brain.  What I extrapolate from it is that for each context switch a developer faces in a day, their brain tires a bit and their work suffers.

I’ll let the article speak for itself:

Why is making a determination so taxing? Evidence implicates two important components: commitment and tradeoff resolution. The first is predicated on the notion that committing to a given course requires switching from a state of deliberation to one of implementation. In other words, you have to make a transition from thinking about options to actually following through on a decision. This switch, according to Vohs, requires executive resources. In a parallel investigation, Yale University professor Nathan Novemsky and his colleagues suggest that the mere act of resolving tradeoffs may be depleting. For example, in one study, the scientists show that people who had to rate the attractiveness of different options were much less depleted than those who had to actually make choices between the very same options.

So let developers have some privacy to go along with agile development practices.  A little bit of both will lead to productivity gains.  The science doesn’t lie.

This post brought to you by Programmer's Paradox

That’s my take from Steve McConnell’s latest post and I completely agree with him.

This post brought to you by Programmer's Paradox

The book has to be one of the best designed books I’ve seen, which immediately lends credibility to Joshua’s message.  There is judicious use of white space which makes the book easy on the eyes.  Colors are used effectively to draw attention to important points and tying it all together are a wealth of screenshots, which clearly illustrate the concepts Joshua writes about.

The book starts out simply enough by outlining how the web has become more social as it has aged.  It then progresses from there through several topics that will likely seem obvious to anyone immersed in the web, such as the need for businesses on the web to have authentic conversations with their users and the various hurdles one can encounter when signing up on a website.  However, while it’s easy to write off the content as obvious, the real benefit of the book is that it investigates and brings to the fore underlying assumptions.  It’s easy to forget something that seems obvious, so it is invaluable to have a source that points out the mundane and forces designers to consider all the implications of their actions.

The book really shines in the final few chapters.  Joshua examines how to design features for sharing content and he does an excellent job of breaking the sharing process into individual steps.  Sometimes I think those who design web applications fail to examine each small piece of a design and as a result the design fails.

In the final chapter Joshua explains the funnel analysis process for examining how a web application is performing.  As Joshua notes in the book, this analysis process greatly resembles the scientific method and that this was no accident.  Too often designs are based on feel and not enough on actual numbers.  While some of both are needed, I think a move towards a more scientific process would be a good thing, and I appreciates Joshua’s efforts to move the discipline in that direction.

The book does end abruptly with the final chapter.  A short summation would have been welcome, but this is a minor quibble.  Perhaps the greatest testament to this book is that while reading it I started applying the techniques discussed to my current project and instantly saw ways to make it better.

I recommend Designing for the Social Web for all web designers and even for web programmers like myself.  It shows all the small parts to consider in a design and how carefully paying attention to each can lead to a better design.  You’re guaranteed to pick up on something you’ve overlooked in the past.

You can order the book on Amazon here.

This post brought to you by Programmer's Paradox

The one downside to Thrift at the moment is that it has very little documentation.  Everything I’ve learned has been through trial and error or by watching other developers at work.  If I get a chance I hope to provide a sample Thrift implementation, using Python, along with documentation.

Until then, Stuart has provided a nice overview of Thrift’s features by comparing it to Google’s recently released Protocol Buffers.  If you’re interested in either, read Stuart’s article.

This post brought to you by Programmer's Paradox

I wish him all the best.  Now comes the hard part: finding other bloggers to replace him in my RSS reader.  I glanced through my reader today and realized that Raganwald was the only blogger I had in my reader who consistently updated with strong technical, code focused posts.  That is depressing.

I need recommendations of bloggers to follow who can fill this void.  Please post any you have in the comments.  I’ll let you know if I come across any one who looks promising.

This post brought to you by Programmer's Paradox

Now that I have some free time again, I’m going to kick things off with a series of small posts, and then I’ll try to get to writing some longer and more insight posts on topics I’ve been meaning to write about.  Some topics I plan to address include a post on management and Twitter, several posts on the No Fluff Just Stuff tech conference, and a post on the meaning of trust in the work place.  I’m also planning to try and write more technically oriented posts that I have in the past, as I’m currently doing work in Python and plan on learning Ruby.

Thanks for sticking around.

This post brought to you by Programmer's Paradox

It is a small conference that is generally very technical in nature.  I highly recommend it.  Speakers such as Neal Ford, Ken Sipe, and Venkat make it very much worth while.

On another note, don’t expect any more updates for a couple of weeks, due to events in my life.  I’ll try to blog a series on what I learned at NFJS once I have the time and everything has calmed down.

This post brought to you by Programmer's Paradox