JRugged cross post...

Look ma, I'm Famous. ;)

Xfinity Labs

HttpComponents - Caching Module

Something that I have been working on with some people that I work with:

Benchmarking the HttpClient Caching Module

It was my first foray into submitting to an opensource project.  I have had a lot of fun working with the team and with the Apache moderators in getting this into the 4.1 version of the HttpClient, which is in beta/RC currently.  The caching client supports HTTP 1.1 response caching.

The beta can be found here:  HttpClient Dev Site

If you use HttpClient - I encourage you to down load this new version and take a peek at the caching client.  We would enjoy getting feedback on the usefulness of the tool and how it can be improved.

Volkswagon - An unavoidable rant

Long Time Owner
Let me first lay the groundwork for this post.  I have been a very long time VW owner and enthusiast, from as far back as when I was thinking about my getting my own drivers license.  Before that my family owned VWs as well, my father had a brown gasoline rabbit (1972 I think) and my mother owned a silver diesel rabbit (a 1979 I believe).  I owned a number of odd cars before also getting my first VW, which was a 1997 Passat 1.9 TDI Sedan.  In between my other cars and finally getting the 1997 TDI, I purchased a diesel rabbit for my wife which eventually was replaced by a 1994 Jetta, which was then replaced with a white roll top Cabrio.  As the Cabrio declined, her and I switched cars for a little, while my wife bought her first brand new car purchasing a new green metallic Cabrio with a tan convertible top.

To say that I like my VWs is a bit of understatement.  Now to be sure, I am NOT as hard-core as some, but I have been very loyal to the VW brand.  The cars are generally fun to drive, easy to repair and maintain for the average gear head and at least for all the VWs I owned relatively cheap to own and maintain, that is until my purchase of a 2003 Passat gasoline 1.8T Wagon.

Track Record
In fairness before I get into the rant proper, all the VWs I have had have had some trouble with specific items.  The diesel rabbit had the 'rabbit leak' over the fuse panel giving it all sorts of interesting issues including a propensity to short and run the battery down while it was 'sitting' for multi-day periods.  The same problem was prevalent in the white Cabrio that my wife had for a while.  Despite those problems the cars continued to operate and run and the fixes for any 'major' problems either of those cars ever had averaged a MAX of $500.  We had a belt wear out on the 1994 Jetta, never had any trouble with the green Cabrio right up to trading it in on the 2003 Passat.  The 1997 TDI that I purchased had relay109 fail, has gone through a number of window regulators and other than normal maintenance has had few if any real problems.  My TDI currently has 215,000 miles on it and recently got the infusion of the largest amount of TLC that it has ever gotten when I spent $3200+ to do the following:

• Belts + Pulleys
• Suspension on ALL 4 corners
• Struts, Springs, etc.
• Water Pump
• Window Regulator on the Drivers Side
• Add a CCV Filter (Mann Provent)
• Remove and Clean the Intake Manifold
• Remove and clean the Intercooler and Piping
• Replace the Entire Exhaust from the Turbo Back to the tail (The OEM had essentially fallen OFF the car)
• New Clutch
• Starter Cleaning/Rebuild
• Water Thermostat

Some of this work I did myself while some I had done at my local repair shop.  In total I may have put $5000-$6000 total into the TDI since I purchased it new in 1997.  I CANNOT say the same about the 2003 Passat Wagon, and hence this rant.

The reason I will NEVER own another VW Automobile
The 2003 Passat Wagon 1.8T is 100% the reason that I will never own another VW in my life.  This car has had so many problems that it makes me slightly sick:

• Fuel pump
• Fuel level sender/indicator
• Water Thermostat
• Radio Antenna Shorting/Rusting
• Moon roof 'Flooding'
• Ignition/Coil Pack Failure
• A/C Bearing Failure
• OIL SLUDGE (x2)

and - recall after recall after recall.  In fact it seems like every time we got a recall notice on a part that part would then fail forcing us to tow it, due to failure while driving, and get the recall item replaced.  This car has stranded my wife in intersections and other situations too numerous for me to count.  Even with all these issues it is the last one in the list that is the worst of them all because it appears to be the one thing that VW wanted to 'hide' after it started to occur on ALL of the 1.8T engines, an engine oil sludging issue of class action lawsuit proportions.  Lets look at the situation from my point of view; the 1.8T engine seems to have the following issues:

1. An oil sump that is too small
2. A quantity of oil that is also too small to dissipate the engine heat appropriately
3. An originally specified oil filter that is too small to cope with oil sludge that occurs because of 1 and 2
4. A turbo that can get hot enough to glow with a slight cherry color
5. Insufficient cooling of the turbo means that engine oil comes in contact with VERY high temps compounding oil sludge issues
6. Using 'conventional' oil compounds these issues
7. Oil screen and uptakes that are too small

So - at first the documentation for the car did not indicate anything special about the oil to be used, just normal oil with a specified weight.  Then an update addendum from VW indicating that only 5w-40 FULL SYNTHETIC oil should be used.  Shortly after that update was received - the oil pressure light in the car came on despite there being plenty of oil in the car.  On taking the car to VW - they indicated that the engine was sludged and the repair would be $1800.  They said that they would cover the cost if I were able to produce every oil change slip I ever had to prove that I had done what was asked of the dealer and VWNoA (VW North America).  Of course I don't have every slip for every oil change, and of course I did not take that car back to the dealer every time for its oil change - because that is expensive and insane.  So $1800 dollars later, we got the car back.  Fast-forward to today - and the car has the sludge problem AGAIN.  This car has been problem after problem after problem that has essentially left us wondering WHEN it will fail next, not IF it will fail next.  This engine was poorly designed from the start giving it a propensity to sludge and fail sometimes catastrophically. 

Post after Post after Post after Post after Post of people with the same oil sludge problem and VWNoA essentially turning a blind eye to the problem.  The engine should have just been recalled en-mass because it was prone to this issue.

No car I have EVER OWNED has had this level of problem with oil sludging.  Not my TDI, not any of the rabbits, cabrios, jettas that I have owned have ever had a problem like this, even with some serious abuse of the change intervals - NOT A SINGLE SLUDGE PROBLEM.  Change with conventional oil, change with synthetic oil, change with some mix of both in the same engine... not a single problem.  The 1.8T seems to MAKE sludge due to its design.  It would have been interesting if VW had made some improvements/revamps to some engine parts to attempt to address this issue.  Instead VW redesigned the whole thing in a beefier 2.0T engine and did away with the 1.8T engine all together.

Quality Counts
I have never felt so abused/betrayed by a car in my life.  Every time I turned around there was another problem leaving my wife stranded in the middle of nowhere.  If it wasn't the oil sludge costing me money it was the fuel pump (eventually recalled) or the ignition coils (also recalled) or water in the cabin from the moon roof drains being clogged.  This by far has been the worst VW I have ever owned and despite a long history of VW ownership - this car has caused both my wife and myself to turn away in disgust from VW in general.  VW's inability to take responsibility for poor design and parts choices is inexcusable in my mind and I cannot take the chance of getting another car like this one.  Sorry VW - with this latest round of engine oil sludge in my 1.8T (despite religious, possibly even anal retentive oil changes) you have just lost a long time customer (from childhood till now) of your cars.

JRugged - Making your code more RUGGED

Cowboy coding
We have all done some cowboy coding at some point in our life.  I think we can even recognize when we may be asked to perform our cowboy coding.  The scenario is something like:

Your boss or your boss's boss comes down and says "... we have to have this new thing - and we have to have it by this deadline or the sky will fall and we will all die..."

It is at this point that as a developer you begin to run through how you might develop what is being asked for and work through in your head exactly how you will tackle the problem at hand.  It is also usually right at this point that decisions about what short cuts need to be taken in order to get the job complete on time get made.  We, as developers, short cut things like:

• unit-testing (because we tend to do it after development, making it feel superfluous)
• monitoring/data collecting about the system we are developing
• resilience to failure

These last two items, monitoring and resilience to failure,  are the focus of this post.

Out of the box monitoring
When I mention monitoring what is the first thing that comes to mind?  Is the machine my software is deployed on running?  Does it have connectivity?  What is the program’s memory footprint?  How much free memory or disk is available?  While all of these are important base questions to know the answers to - they do very little to help you understand your running, deployed software.  To understand your running software you need to be able to answer questions like:

• How many requests per second has my software performed in the past minute, hour, day?
• How often did my software fail in the past minute, hour, day?
• How often did my software succeed in fulfilling a request in the past minute, hour, day?
• What was the latency for the calls that were made into my software in the past minute, hour, day?

Fault Tolerance
How often is it that case that the software you build has to call an outside resource?  Maybe your software needs to make an API call to another system to get some information/data or maybe your system has to integrate with a remote system in a specific way; how do you insulate yourself from that other system's failures?  How do you go about keeping the system you develop responsive and allowing it to fail quickly and respond back to the end users in a gracefully degraded way?

I believe that making a software system that "gracefully and quickly" fails when an outside resource is not available is usually accomplished by introducing something like timeouts, retries or other systematic back-off mechanisms.  Adding timeouts or back-off can be problematic and can cause additional unforeseen issues like threads that hang or thread counts that run out of control.  What we really would like to do is detect errors and if the error rate is high enough turn off ALL remote calls to that resource to save the user and the system from the cost of having to 'wait' for timeouts to occur.

Enter a Java project that helps you move beyond out of the box monitoring and timeout-based fault tolerance with ease: JRugged.

JRugged
JRugged provides straightforward add-ons to existing code to make it more tolerant of failures and easier to manage/monitor. In other words, it makes your Java code more rugged!

The purpose of the project is to help answer the questions we posed above in a straightforward and easy to understand way.  By answering questions like how many requests per second am I processing currently, JRugged makes it dead simple for any project to be able to gather and understand the metrics for their running systems as well as assisting in making those production systems as resilient to failure as possible.

For collecting performance statistics we have a PerformanceMonitor object that provides the following output:

RequestCount: 26
AverageSuccessLatencyLastMinute: 974.3247446446182
AverageSuccessLatencyLastHour: 1051.3236248591827
AverageSuccessLatencyLastDay: 1052.9298656896194
AverageFailureLatencyLastMinute: 0.0
AverageFailureLatencyLastHour: 0.0
AverageFailureLatencyLastDay: 0.0
TotalRequestsPerSecondLastMinute: 0.34042328314561054
SuccessRequestsPerSecondLastMinute: 0.34042328314561054
FailureRequestsPerSecondLastMinute: 0.0
TotalRequestsPerSecondLastHour: 0.006920235124926995
SuccessRequestsPerSecondLastHour: 0.006920235124926995
FailureRequestsPerSecondLastHour: 0.0
TotalRequestsPerSecondLastDay: 2.893097268271628E-4
SuccessRequestsPerSecondLastDay: 2.893097268271628E-4
FailureRequestsPerSecondLastDay: 0.0
TotalRequestsPerSecondLifetime: 0.6241298190023524
SuccessRequestsPerSecondLifetime: 0.6241298190023524
FailureRequestsPerSecondLifetime: 0.0
SuccessCount: 26
FailureCount: 0

For adding fault tolerance and resilience we have CircuitBreakers.  CircuitBreakers provide the following characteristics:

LastTripTime: 0
TripCount: 0
ByPassState: false
ResetMillis: 10000
HealthCheck: GREEN
Status: UP
FailureInterpreter: org.fishwife.jrugged.DefaultFailureInterpreter@39ce9085
ExceptionMapper: null

There are three modules in the project:

jrugged-core
Contained in jrugged-core are building block classes that can be used by independently to build out functionality within your application.  Most of the items in jrugged-core utilize a simple decorator pattern allowing them to be easily inserted into your existing Java projects with little or no impact.

For example, if a developer wanted to wrap a performance monitor around a section of code for a backend call it might look like the following:

public BackEndData processArgument(final String myArg) { 
     final BackEndService theBackend = backend;
     public BackEndData call() throws Exception {  
          return perfMonitor.invoke(new Callable() {    
               public BackEndData call() throws Exception {
                    return theBackend.processArgument(myArg); 
               }
          });
     }
}

If you were then interested in the number of requests per second made to that back-end you could interrogate the 'perfMonitor' object to find out.

jrugged-spring
The jrugged-spring library is built upon the classes and items exposed in jrugged-core to provide an easy Spring integration path.  jrugged-spring provides Spring interceptors that can be utilized in conjunction with a Spring proxy to 'wrap' methods in classes based on  regular Spring configuration files.   If you are currently using Spring, this is the way to go, as there is no change to your existing code needed.  Just add needed lines to the Spring config and you automatically have the performance information gathered into an object that can be exposed easily with JMX.

jrugged-aspects
Similar to the jrugged-spring library, the aspects library provides the user with handy annotations that can be used on methods to wrap the performance monitoring or circuitbreaker classes around the target method.  Getting statistics or incorporating graceful and quick failures becomes simply a matter of adding the appropriate annotations and assigning a name to get it to start collecting information or providing the fault tolerance of a circuit breaker.

What is the take away?
Having lots of information about how our software runs and handles failures is important to the business and we should already be building mechanisms into our developed code to provide them; the problem is that there is rarely time to do so.  JRugged makes adding these critical components to your software so easy that it would be criminal not to add them.  Please go and check out the project at http://code.google.com/p/jrugged/; we are always looking for comments and enhancements on how this works out for you and suggestions for future enhancements.

all about being "Good enough", not the best

To be honest, I do not believe that people will move from an iPhone to an Android handset because it happens to have cool or 'must have' applications; I believe that people will move from one to the other because the Android platform is 'good enough', has enough of the same features, is cheaper than the iPhone.  I don't buy into Steve Job's idea that quantity of quality applications is what matters - the statement pertaining to application quantity or quality is marketing fluff that works only when the sheeple take it in fully and lasts only fleetingly before the American populace is onto the next thing, keeping up with the Jones'.

I draw similarities between the marketing done for the iPhone and its applications to Rosie the Riveter. When the war was over and all the women who had been working to make the machines of war for their men who were off fighting were being told to go back to the house and the kitchen so that the returning men could have jobs, common marketing and media helped to reinforce the idea that doing so would be good allaround.  You saw shows like Leave it to Beaver and other media outlets depicting the perfect house wives in high heels, cooking and cleaning.  Eventually that pervasive depiction of the perfect house wife became a main steam understanding again and womens place was the house and home, the kitchen, doing house work in heels and having dinner on the table when their 'Man' came home.

People don't specifically need killer android applications in order to choose the Android Platform.  They need something that is 'good enough' or 'similar enough' at a reasonable price.  Given a choice people might choose the iPhone to have the same thing as a friend driven by pressure from their friend to purchase and pay the premiums associated - I believe what will eventually happen is that the pressure applied will dissipate, the need to keep up with the Jones' will dissipate and 'good enough' will do for most people.  I do want Android to be a great platform, but honestly I think having something 'good enough' that allows me to do as I please with the device is much more appealing - voted with my dollars and purchased an Android phone when I could have gotten the iPhone 4.

Feeling like a hero should be your sign, something is wrong

I was reading the following post on "Work Around Cultures" and got to thinking how many places I have worked or listened to friends of mine talk about their jobs and how all but one of the places I have worked and a fair number of the places that my friends work fall into the category of "Work Around Cultures".  Now to be fair - the post is about Medical work places, but I believe it to be just as applicable to the software companies that I have worked for in my career.

The article points out that there are several consequences to what the author calls "Patch-It" work arounds.

1) Increasing medical error
Work-arounds lead to interruptions, which in hospitals are associated with errors and accidents. They increase the cumulative workload for nurses; higher workloads are associated with worse patient outcomes.

The same sort of issue can be found in IT departments and operations groups where work-arounds lead to interruptions and errors due to the work-around not being well documented or understood.  Consider the following: a work around is done by one person, the next person that works on that system has to remember that a work-around was done or know who to go talk to about the work that had been previously done in order to work with that system.  This can lead to errors and mistakes.  Granted - the mistakes made are not generally life and death but can be costly nonetheless.

2) Wasting resources. 
Individually, work-arounds don’t appear to waste much time, but studies have shown that required hunting and fetching eat up as much as 36 to 60 minutes per 7.5-hour shift.

As you can well imagine from #1, when you need to make a change to a system or need to make an operational change having to find an individual who made a work-around can be costly in terms of the time required to go track down the needed information.  It would be my speculation that the amount of time wasted would be very similar to the numbers indicated in the article if not more.  Having to deal with the work arounds will cause people a great deal of hassle trying to figure out what the work around was meant to do and who put the work around in place in the first place. 

3) Promoting employee burnout. 
Persistently lacking resources required to do one’s job takes physical and psychological tolls that lead to nurses’ burnout.

Again leading from #1 and #2, you can well imagine that people would eventually get very tired of having to go track down work arounds and the people that performed them.  I can hear everyone I have worked with in the past saying something like "... I was not hired to do this, I was hired to X..."

4) Creates a work-around culture. 
When work-arounds are common, people are less likely to seek system improvements.  There’s an insidious aspect to the culture that causes people to dismiss notions of improving things and learn to live with imperfection.

Work arounds seem to beget work arounds similar to telling a little white lie that you then need to cover up with another little white lie or even bigger lies.  I believe having to work around things in an IT culture equal to the idea of technical debt.  There may be a good reason to incur debt and to perform a work around as long as you make the space and time to go and 'repair' the work around.  Left in place how ever, work arounds can be a drag on the culture and lead people to believe that things will never get fixed.  Worse - people my start to believe that the work arounds are EASIER than working to actually fix the underlying problems.

The article points out that having a work around culture can be compelling to people because it provides a way to get the job done.  Paraphrasing and translating from the article the work arounds provide a way for the worker to 'get the job done', not involve the manager (keeping managers and works happier), and foster a hero like feeling.  The work around culture however is terribly detrimental to the organization because it can translate into a compiling list of work arounds that might never be solved, possibly leading to the need for "The Big Re-Write" of the developed software.

“There’s an insidious culture of ‘That’s just the way it is around here.’”
     — Anita Tucker

Managers can help alleviate this by setting a tone that indicates that they would like workers that report to them to report issues that they find.  Doing so has to go hand in hand with actually doing something about the reported items but in most circles doing something about reported issues is the easy part.  I personally work always to make sure I am attempting to address the root causes of problems and not just tossing a band-aid on problems.  I don't like to repeat work I could have saved myself from doing it better or right the first time.  What does your work culture support?  If where you work would rather you patch it, work around it and ignores the root causes ... it might be time to look for a new job.

Professionalisim (Software Engineering)

Software Engineering is a discipline much maligned by a fair number of people.  Actually - what bothers most people is the idea that developing software is an 'Engineering' practice because it places software developers on a level playing field with civil, chemical or materials engineers (or any engineering discipline).  Engineering disciplines require certifications and testing and a great deal of knowledge that all gets boiled down to 'permits' and other legal documents that determine an individuals qualifications to be labeled an 'Engineer' none of which software ENGINEERING has currently - all you have to do to be labeled a software engineer is 'develop software', that is it - no fancy diplomas, no permit tests, no other qualifications required.

There are some indications however that this is changing from the inside out.  Software engineers would like to be considered highly professional people and are talking about what it takes to have professionalism in software engineering and have it represented as a top notch profession.

1) Your code must be clean
Take this point as you will - your code must be clean, easy to read, and easily maintained.  You shouldn't have overly complicated methods, unrecognizable variable names, and just plain nasty nested if, else statements.  Think twice about class files that are over 1000 lines long, methods that are over 5-10 lines long... take the time to take pride in your work (like me editing this ... again).

2) Your code should always include unit tests
Unit tests do two things - one they help you to validate that what you have written is what you intended and two they provide a way for you to verify after you re-factor to get to the first goal of having clean code that you have not broken anything.  Unit testing provides a very critical safety net - you are lost without.

3) You should practice
Programming like anything else requires practice to make you better and to keep skills sharp.  Doing programming katas in your spare time to exercise the skills needed to have clean code and always have unit tests is of vital importance to being professional.  If you were in the NFL or baseball or any other sport or musical profession you would need to practice to keep your skills up - programming is no different.

4) It pays to be multi-lingual
The basics of programming are essentially the same no matter the language that you typically program in.  Because of that - lots of programming languages often look very similar but have subtle differences in their syntax or effect when they are executed.  It can be beneficial to know several ways to skin a given cat as well as to understand what tools are best suited to a given job.

5) Pair Program where possible
Learning can be a two way street (and often is) so it pays to pair with someone when you are doing work - you can have one person writing failing tests that the other person makes pass.  It can be eye opening and enlightening to have someone to talk with and discuss ideas with while you are working on coding out the solution to a problem.  you may find your self writing far less code than you may have otherwise if you include a partner.

Is it possible to be professional without the above items?  Yes - I imagine that it is, but I believe that if you want to call yourself a professional software engineer, you should be doing the items above at a minimum and including everything else as just common place.

Businesses and Money

A business that makes nothing but money is a poor business.
--Henry Ford

Critical Thinking

So - its election season, there are a great many commercials on about all of the people that are running for election this year.  I would say my perception of these commercials is that every single one of them is vitriolic and finger pointing - calling the other candidate(s) to the mat, blaming them for everything from babies dieing to global warming.  These commercials count on being able to make the viewing public THINK the way that the makers of the commercials would like.

Why do I mention this at all, you may be asking.  Well I ran into a blog post based on a tweet from a friend of mine.  The post is talking about people being misinformed or under informed and being happy to essentially remain that way.  The post points out that a seeming larger and larger population of people break their world down into sound bites and small 'parroting' points that allows them to glom onto someone elses opinion on a particular topic.  This process of not thinking critically about the information that is being presented provides a reinforcing factor for individuals being uninformed on topics ranging from politics to home cooking to sex. 

Listen folks - it is easier than it seems to get information on all sorts of interesting topics, including topics pertaining to elections in the US.  The internet has made the information infinitely more available than it was previously - leaving little excuse if you don't spend time reading or at least looking for information to corroborate the things that are 'dished'/'spoon feed' to you on tv and popular media.  The same statement holds true for information and communication in your day to day jobs.  Please - think critically about what you are told, look for additional information from other sources - spend time attempting to put yourself in other peoples shoes and asking in your head "WHY" someone might have said something the way in which they did, specifically to you.  You will be better off for spending the additional time in comparison to just thinking like 'They' want you to think. 

Consumable Software

I will warn all of the readers of my blog in advance, THIS WILL BE A RANT - I am stepping up onto my soapbox currently.

I recently had reason to attempt to install and use ReviewBoard - a software review management system.  ReviewBoard is written in Python, on the Django CMS framework.  In and of itself, ReviewBoard caused me no specific pain - now installing it into my environment is a completely different story.  I will freely admit, additionally, that the company that I work for currently has chosen Solaris as the platform of choice for their systems which added to the complication and heartache I had attempting to install ReviewBoard, in fact making the install nearly impossible. 

<rant>
ReviewBoard was easy to download - Check in their Favor
ReviewBoard works on several different versions of Python - Check in their favor
ReviewBoard has a bunch of Python package dependencies - and here is where the issues begin.

Python has precious few pre-built things for Solaris (SPARC or x86).  This means that ReviewBoard needs to compile a bunch of libraries in order to function correctly.  Those libraries were not available in the ReviewBoard download - the were not bre-bundled in the ReviewBoard tar, they had to be downloaded.  NOW - ReviewBoard does have the knowledge to go and attempt to grab those dependency downloads for you so you don't have to go track them down yourself.  Yea!  I am however much more of the option that the software should have the 'Version' of the things it needs to run included with it - the software should not be 'required' to download it in order to work.  This requirement is about its specific software dependencies and not tools like MySQL that software might depend on.  Those are requirements to setup the system, no specific dependencies in my definition.

OK - Now I have a bunch of stuff to compile, that failed.  Solve the libs issues, build, fail, rinse and repeat for HOURS.  Eventually get the whole thing to compile correctly.  ReviewBoard is now installed - but you still have to setup a 'web' site that contains ReviewBoard.  The task also had dependencies that had to be worked out - and did not work out of the box.  Even if it was Solaris - the whole thing should have been easier.

OK - Now there is a ReviewBoard site that is setup, you can hit it with a browser, but it still needs to be configured with interesting things like where is your current source code repository.  Login to the ReviewBoard site you set up, attempt to configure the site and "LD LINKER ERROR" missing a specific library in the OS.  Which library is missing?  What additional thing needs to be installed?  Was it a compile error even though it didn't report any problems?

In the end - I never really got it working.  This was probably due to Solaris more than ReviewBoard specifically, but there were a-lot of problems.  I feel strongly that ReviewBoard as a site should have worked OUT OF THE BOX, and not required as much work on my part.  I imagine also that there were design decisions that would have effected my specific experience that were made in the past about how ReviewBoard would be put together - like the choice to use pysvn API integration rather than using the command line client and parsing output.
</rant>

When you want to build something for someone else - the easier you can make the setup/install for them, the more they will see the care you took and the more likely they are to persevere when it comes to using the tool.  However when the experience is like what I experienced - I am left feeling like I never want to look at ReviewBoard again.  Chose the simplest thing that removes dependencies from your tool to make the install even easier.  First impressions are EVERYTHING, if peoples first experience is a shitty one, even if it is not specifically the fault of the software attempting to be installed - that bad view will be pervasive and stick with you.

Agile Autonomy and Commitment

A recent post Should Agile Teams have to Call Their Shots got me thinking.

Calling pool shots == Velocity prediction

Mike makes the statement that calling your pool shot each and every time you shoot the cue is akin to being able to predict the outcome of a sprint iteration. The analogy is interesting but I think a little imprecise. Professional pool players - at least the 8 ball players I have seen on T.V. - have the ability to shoot the cue, hit the ball they want and have the cue glide into the near exact position needed to make their next shot. Pro-pool players seem to do this without really thinking about it (at least that is the way it appears on the T.V.). Similarly scrum sprint teams have to execute work for a period of time and when that time box is up be ready to do the next needed thing. However the sprint team can do this without ever needing to know their velocity at all and they can repeat the cycle over and over without the knowledge of their velocity. Velocity is important in predicting how much a team can do - but is only useful in predicting 'what' a team can do by providing a bar to say that something is too big or too small to fit within an iteration cycle.

Trust

Calling your shot in terms of scrum sprint teams and their velocity measurement is really about creating a level of predictability for the team and the organization as well as generating a level of trust for delivery with the business partners. Unlike the pool example - there is an external group beyond the individual that has to be able to count on the team committing to and delivering on promises so that the organization as a whole can be setup to execute the next set of work without having to worry about items that did not get completed because a team missed the mark. In the pool example there is only a single person and only that persons call of the shots matter - it is hard to scale that example up to teams with multiple people all of whom have to understand the team commitment and the need to follow through. Equating the single person in pool to a single team also doesn't seem quite right for the reason I laid out above... a team doesn't need to call the shot in order to do work in iterations, but they do have to call the shot in order to generate trust that they can 'predictably' do iterations. It is the trust and predictability that allows planning beyond one iteration for the organization.

I think a better analogy would be something like the team being able to reliably hit a bulls-eye in darts. Hitting the bulls-eye in darts requires skill and practice. I believe it to be the practice part of dart throwing that was missing in the pool analogy presented. Teams will not have any knowledge of their velocity when they start out and it will be difficult if not impossible for them to "call their shot" until they have run through many iterations and actually gelled as a team. As they practice however - they will get more consistent and more accurate. However, in those first few sprints, despite not having a consistent velocity and provided that they commit to and complete work that the team agrees can be done, the team will be building the trust with the business and management that as they get more accurate in their velocity measurements the team can be counted on to complete agreed to work in a given iteration.  This is when the benefit of knowing your velocity can be seen. 

Mike was right that knowing the team velocity is important for planning and laying out releases and things - but I would argue that trust that the team will complete what they sign up to complete is far more important.

Steve Jobs Open Letter

In an open letter (also available directly from the apple website, here) to the world, posted on engadget, Steve Jobs attempts to layout his reasoning for why no flash and other "third party" libraries on the iPhone, iTouch, and iPad.

I am going to pick a little on point number six from his letter:

"Our motivation is simple – we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen. We want to continually enhance the platform so developers can create even more amazing, powerful, fun and useful applications. Everyone wins – we sell more devices because we have the best apps, developers reach a wider and wider audience and customer base, and users are continually delighted by the best and broadest selection of apps on any platform."

Yes Steve - this can be thought of as a laudable goal. The problem, you see, is choice. In some respects "...if you build it, they will come..." holds true when you talk about cool features and tools to make applications. However, making the choice to not allow ANY THIRD PARTY tooling (flash not withstanding) you are restricting all the other people that might not want to learn Objective-C in order to program for the platform. True - there are plenty of people willing to use your tools, as the number of applications currently available demonstrates, but if the number of applications 'COULD' be 10X as large if you allowed Java, C#, other languages into the space without compromising quality (which you shouldn't be able to control in the first place Steve) would you say that's a good trade off?

I am not sure I buy into the simplistic argument that Apple is using to draw this particular line in the sand.

...To make sure people can 'always' make use of the latest and greatest platform features...

Is it not the case that anyone that wants to do that should be able to make the CHOICE to utilize Objective-C as their platform for coding applications. However, if I am not always interested in the latest or greatest features, essentially I don't care about the cutting edge, I just want an application to work... why can't that type of thing be done in another language and without compromising the supposed quality/availability that you taut.

Sorry Steve, I am just not buying it - literally and figuratively.

The Great Debate

So - The new shiny thing is out for the iPhone, OS4, which contains a change in the Terms-of-Service that seems to have everyone talking. There are some great posts discussing the TOS changes from John Gruber over on Daring Fireball, here and here. There is also some additional commentary, including an email exchange with Steve Jobs, over on the TaoEffect - here with a follow up due to user comments here.

What I have been wondering reading all of the various commentary about the TOS change is this:

Other then form factor, what makes the iPhone platform so substantially different from a MacBook?

You could talk about computing power, the iPhone obviously has a lot less over all computing power then a MacBook. Yes, very true. So what - it still seems to run programs just fine.

You could talk about screen size, the iPhone screen is obviously a lot smaller then your typical MacBook @ 15 inches or so. Yet somehow the information from the programs on the iPhone still seems to make it to the user just fine.

You could talk about the lack of multitasking, however as I recall macs well into their golden age, before OSX came out, used to do cooperative multitasking (which arguably gave the appearance of multitasking without really doing it) - which with a few tweaks looks alot like the multitasking being introduced in iPhone OS4.

On the MacBook I can write applications in:
Ruby
Python
C
C++
Objective-C
Java
Perl
Erlang
JavaScript
And the list goes on.

On the iPhone I can write applications in:
C
C++
Objective-C
JavaScript (WEBKIT Only)

So the only substantial difference is the programming languages I can utilize to write for the platform? Ok, I admit that this is an oversimplification of the situation, but it does make for a good talking point.

So why is the iPhone so limited in regard to the languages one is allowed to use to write applications? I think the answer is simple, Apple is attempting to control every single aspect of how their software/hardware is used in the name of 'Good user experience'. Apple has, as a company, always tended to lean in the direction of 'control everything' - take their historical stance on mac clones as a for instance. However the control Apple is attempting to wield on the iPhone is much tighter then that of the computers that they also market. I can write in any language I choose on the MacBook - but I need Xcode, Objective-C and Apples blessing to write an iPhone app. The platforms are not different enough to warrant the 'language' restriction. Add to the concern that the last item on the above list, Apple's blessing, can be very difficult to come by if your application happens to compete with Apple's interpretation of 'good user experience' (i.e. if what you write using the tools they say, competes in anyway with the built in functionality).

It seems to me that Apple is not interested in the user experience - just their own bottom line... like any other market driven company. Apple's stance seems to be working, at least for now, based on their current stock price as of the time of this post. I do question however if the stance Apple has taken will work in the long term - people may start to take notice and do what I have done... vote with my dollars and not purchase the things that they produce. Essentially avoiding the 'Apple Tax'. Make no mistake, this is not an Apple bashing exercise - I believe that they do make a very unique user experience and a lot of coders could learn from the 'little' things and polish on development that they do so well. I just think that those things don't make up for a corporate stance that is attempting to squeeze everything that isn't C based on a Mac out of the iPhone development picture.

Code Quality

I am taking a little poll: What does 'Code Quality' mean to you?

Joel equates quality software/code to being useful to the purchaser (in this post)

Quality to me means a variety of things to differing degrees including:

• Unit tested
• Functionally Tested
• Maintainable
• Supportable

If we are going to talk about web based software I might also add

• Scalable
• Having the needed capacity
• Being highly available

Obviously if the software isn't useful - no one will buy it, but I think encapsulating the entire argument of 'Quality' into that simple of an equation to decide if in your startup it is the right time to hire sales and marketing, while possibly being right... is a tad short sited. So what is quality to you?

Thoughts on the iPad

I have read a few different view points on the iPad's release and been involved in a few discussions on the same - there are lots of people discussing the space that it wants to live in, will it sell, is it a disaster or a boon and what does it do for innovation. Its this last point that I see a number of people talking about what Apple is doing as a company with the product they have produced.

Lets look at things from Apple's point of view:

• iPad leverages ground that Apple has already covered/uncovered
• The iPad contains an OS that they already existed
• The iPad leverages all the goodness for consumers that iPhones already brought to the table.
• The iPad makes use of the same UI and user mechanisms, which is HUGE. Lets all admit that changing user behavior is generally damn near impossible.

iPad is a natural extension of the systems that Apple already has in place based on the above. It fits into Apple as a company - like a glove.

A number of people have noted the above and more - while doing so they have also noted what they had in terms of 'HOPES' for what the iPad 'MIGHT' be when it launched. Tech geeks hoped it would be more open (include things like java, flash, python, etc. etc.) they hoped that they would not be subjected to the entirely black box application approval practice that Apple foists on developers. In short they were hoping for something that essentially is not in Apple's best interest currently. Lets be honest, Apple has made alot of money with the iPhone and the systems that surround it, DESPITE all the bitching and complaining that we tech folk are doing about it. Just take this post for example over @ Gizmodo. The reality is Apple is going to continue to ignore the complaints we make because it doesn't help them in the slightest. I do however disagree with the commentary the above Gizmodo post contains saying that Apple ignores these pleas because the DMCA is in place and no one can do anything about it - and more importantly that people saying/asking for Apple to be more open are bitchy complainers who need to "...grow the fuck up...".

History has taught us that things rarely change without there being some catalyst for the change. In essence there have to be COMPLAINERS, people who are unhappy with the status of things in order to make change happen. You can argue that maybe the complainers are complaining about the wrong things... maybe that is the point of that Giz post, but the overall sentiment of that post seems misplaced to me. The entire thing comes back to the same age old argument of 'Apple vs. PC' do I maintain high levels of control over every aspect of the system I am asking people to buy, almost as if I was leasing the hardware (laptop, iPhone, iPad) or do I allow lots of people to mess up the 'beauty' by not caring as much about who supplies the items that go into the machine and allow the buyer to mix and match whatever they want. BOTH choices have their place in the world. I must admit however that I don't appreciate Apple's stand here. They make great stuff for the average user, i.e. it just works (most of the time)... but the BOX it places you in is occasionally very small with little or no wiggle room to do something ground breaking.

Lets take as the prime example the lack of competition in 'certain' iPhone app spaces, things like email, phone functionality, contact management. Applications in these areas are deemed (by Apple) to compete with the built in software, so you will never get your new cool interface idea for these things published in the appstore for availability on the iPhone for lots of people to use, because Apple says so. Not because the application would kill the phone, or destroy AT&Ts network, but simply because it wants to 'Compete' with Apples built in software. The Gizmodo post was correct, Apple, the iPhone and the iPad are not really 'specifically' doing anything that would prevent people from tinkering and programming and gaining an awe and wonder of what that is and what it is like. Apple is however telling EVERYONE that there are arbitrary limits to which they are allowed to play, and those boundaries are constantly changing with no notice with little or no explanation. Competition is acknowledged to be a good thing - but Apple is telling us exactly where we can compete, this I think is what people are complaining about... its not entirely about Flash, HTML5 or other items - but it is more about not being allowed to compete where it MIGHT actually make a difference to the usability of the platform... which BTW has nothing to do with the DMCA and more to do with taking money out of Apple's mouth.

Making the improvments - leaky abstractions

A while back I was reading a post by Jeff Atwood about abstractions in code. Jeff was in turn was picking on something that Joel Spolsky had written, but the gist of the post was pertaining to abstractions in code.

The gist of Jeff's post is I think summed up in the following:

It's our job as modern programmers not to abandon abstractions due to these deficiencies, but to embrace the useful elements of them, to adapt the working parts and construct ever so slightly less leaky and broken abstractions over time. Like desperate citizens manning a dike in a category 5 storm, we programmers keep piling up these leaky abstractions, shoring up as best we can, desperately attempting to stay ahead of the endlessly rising waters of complexity.

Leaky although abstractions may be, they do improve the code - readability, maintainability (other ilities) over time. As Jeff mentions - the question is:

Does this abstraction make our code at least a little easier to write? To understand? To troubleshoot? Are we better off with this abstraction than we were without it?

I think in a large majority of the cases that the answer is yes - the abstraction helps to improve the code in ways that allow it to be better understood by others, easier to maintain in some ways and sometimes hard to maintain in other ways. The abstractions can allow new code features to be easier to write and get into production. In essences code abstractions can help programmers to work to make things better all the time for the next person coming along.

Abstractions can also allow you to get to market quicker and then work to fix issues down the road. This is essentially how I think Microsoft works, get version one out the door and then work to plug the holes in the dike - fix the leaky abstractions that have caused issues. Overtime Microsoft builds better abstractions and better code until something solid that people will like or like better then version one comes out. Personal opinion here is that Windows did/does this, and so does c#/cli. (On a completely side note it is also interesting to note that this build, deploy - revise is something that java does not do very well at all. For all the touting that people make of the JCP, the whole thing seems to be lagging behind what the cli and C# have to offer programmers in terms of ease and simplicity.)

Abstractions are an important part of programming and of how people deal with the world around them... trying to fit ideas and thoughts into buckets of how things are and how they work. People use abstractions because it helps them think about things in ways that are comprehendable/understandable/manageable - this is no different... programming abstractions help us to understand the systems better and make it easier to do certain types of things. Are abstractions leaky? Yes - I think they all are, not a single one of them hits every nail like it was a hammer but they improve things enough to allow progress towards a goal.

Another arrow for the quiver

I have been meaning to post on this topic for a while, but have just now found a little bit of time to squeeze it in.

In the recent past (say about a quarter) I was reading a post by Joel Spolsky about looking for programmers to hire. He made some statements in this post and a post that followed it - some of those statements I agree with and a few I do not and I wanted to take a minute to see if I could spell out both in this post.

In the agree category:

1) It is hard to FIND good programmers.

Interviewing them is not a problem... a fair number of bloggers have pointed to how to hire or interview candidates in an attempt to make sure that you get the best of the people that come through the door. However getting the programmers to the door tends to be an issue. There are two sides to the issue of getting programmers to the door.

* Side one, how does a person looking for a job find my opening @ BigCo.

Lets be honest, there are literally hundreds if not thousands of people looking for jobs in the technical fields, programming included. Of those looking for jobs - not all of them know about the opening I may have @ BigCo. The hiree has plenty of places to go and plenty of places to look for these job openings - Monster, Yahoo Jobs, Joel's Job Board, Dice dot com and of course they can also do the non-electronic thing and search their local paper. Lets call this a well covered area.

* The other side of that coin, how do I find someone who is looking for a job to fill the position that I have @ BigCo.

Above we noted that there are plenty of people looking for jobs, how do I find the candidates that are the cream of the crop... especially if I am looking for the programmers who are the hyper-performers? You know those folk who do 10x more work in the same amount of time as the avg. programmers? Where is the tool that does this type of 'person' finding or person searching?

2) The lack of a good search engine for employers looking for developers hurts

One of the other things that Joel mentioned in his second post is that it is important to be able to ask a programmer search engine just about anything. The fun example he had was students looking for Ocaml internships in Houston. Having a flexible way to look for good programmers who might meet BigCo's needs is important.

In the disagree category:

In the first post by Joel he noted that in an impromptu survey done amongst developers that attended DevDays (a one Day Development Conference) that about three quarters of the audience (75%) were either actively looking for a new job (25%) or at least keeping their eye out for something 'better' then what they had (50%). He posited that the people that attended DevDays are the cream of the developer crop. That the only attendees are the people that love programming and that the attendees are the types who are the 10x developers, the [only] types who participate in Stack Overflow. I would argue that the statement is not entirely true.

It may be the case that the people who attended the conference are the folk who are the most interested in bettering themselves and improving their abilities, but these same people may not actually be the people who are the most productive of their programming brethren. There is no way to really know if any of the attendees are the types of programmers that we might want to hire - the hyper-productive kind.

Joel used the impromptu survey as a lightning rod to say that having that many 'good' programmers displeased with their jobs was something that needed fixing - enter Stack Overflow Careers. This new site allows you to enter your CV and provides all the neat searching and management information to allow employers looking for specific people to find YOU. This site is linked to your information on Stack Overflow, including your ranking and other information for being part of the Stack Overflow ecosystem. This is an excellent idea... however it does not equate to providing an employer a "Guaranteed" winner in terms of hiring a programmer for an open position as Joel seems to imply.

It does the things that Joel mentions, it allows the careers site to be linked to Stack Overflow reputation marks which helps you to "...demonstrate your reputation in the community and show us all how smart you really are." The cross link between careers.stackoverflow.com and the normal Stack Overflow site allows you to essentially prove that you are knowledgeable and can demonstrate a mastery of a particular subject. I would argue however that this alone doesn't provide a full picture of the person that I may want to hire but rather provides just one more piece of information to help me decide if i should hire them.

in the end...

Look, lets be honest - I think of myself as being a decent programmer... modestly I don't think that I fall into the 10x type of programmer, better then most but certainly not like some of the smartest people that I have met in my career. I care alot about my learning and my experience... I attend conferences where I can - and I try to put time into bootstrapping and improving the coders around me, just as I hope that they care the same for me when there is a gap in my learning.

I do not however, participate in Stack Overflow. I don't participate not because I don't think that I could help people but rather because there is limited time for me to pay attention to the other things around me from day to day. My kids, their school and activities, this blog (which admittedly needs more attention but I keep putting it off) and things like my current job and career. There is alot of stuff in my list and limited time to do all of them... Stack Overflow would suck me in to the point of being an addiction and given my other time needs it makes it hard for me to see my way clear to participating. My lack of participation doesn't mean however that I am not a person worth hiring which is what I got out of reading the posts from Joel.

Participation in Stack Overflow may provide an extra insight into my ability to communicate via writing (which admittedly has never been a HUGE strength of mine), but it most certainly does not provide any guarantee that a responder who is also looking for a job is the "cream of the programmer" crop. I for one have run into people who can provide reasonable answers to questions when posed to them... on paper, when they attempt to put those answers into practice however it is a complete disaster and their code SUCKS. Take the Stack Overflow Careers site as just one more bit of information that I might use to 'help' me find and decide if I should hire you - but certainly don't assume that just because the site is where you might find a person to hire that they are the cream of the programming crop, you may be disappointed.