Ponderous Programmer

Death and Craftsmanship

noreply@blogger.com (Joe Campbell) — Mon, 14 Nov 2011 18:34:00 +0000

I have been thinking a great deal about software craftsmanship recently. I have Uncle Bob Martin to thank for making me at least think about it. There is however a life event recently that made me consider the topic in a deep way that I am not sure I really even considered before; you see I had been taking what Uncle Bob was saying about software craftsmanship at face value that is until my Grandfather passed away this weekend.

The Craftsman

When I was younger I used to go over to my grandfathers house, which was not to far from my own home, about 2 or 3 times a month. At the age I was at the time - going to his house was about being able to spend my summer in the pool that my grandparents had, it was about having breakfast, lunch and dinner on the porch, it was about the grill and the amazing food that my grandfather could concoct using it. The time that I spent at my grandparents house was rarely about the things that my grandfather did for work or what he had done as work because my interaction with him was mostly after he retired from the work a day world.

To my knowledge my grandfather worked for Boeing as a machinist making various parts and pieces for either helicopters or for the machines that were machining other parts for the same. What I didn't know until I got older is what an amazing skill my grandfather had for doing what he did - I did NOT realize what a craftsman this man was. You see, my grandfather was able to make the machines he worked with sing and dance to create very specific parts. He was able to set up lathes and other machinery to sharpen existing tools, or create something totally new. My grandfather was able to cause these machines to create parts that had tolerances in dimension of no more then a few 10,000ths of an inch, by hand, day in and day out. When he learned how to do this work he didn't have a CNC machine to program, things were not automated in any significant fashion, he was taught how to make these machines do his bidding by hand, with the lightest of light touches. My grandfather took great pride in what he created - in retrospect, I have that same pride now for what he accomplished doing that work.

Software Development

My grandfathers death and the realization of the talent he displayed when working with machining metal lead me to this, I don't think that my software design and programming should be any different. I should be able to perform gross cutting code as well as fine grained 10,000ths of an inch type code and have it all work. I should be able to call myself a craftsman of software by being able to have someone look at what I have done and say that it is complete and well done. Software craft-persons should be able to look at someone else's work and identify their own craft in it as well as to call out the simple and small foibles made by their compatriot craft-person. Performing the 'craft' of software development, turning ideas into code and doing it with quality and precision, is not easy and not everyone can do it - just like I can't do the things my grandfather did with his machines. However - practice, apprenticeship and other things that go with thinking of software as a craft to master can help you improve what you do, can improve how you think about the work that is software development.

I know from here on out I will be striving to be NEARLY the person that my grandfather was, and nearly the craftsman I know he was in his work. I will work every day to improve how I write my software because knowing who my grandfather was and how he did his work prevents me from doing any less.

Why do POs ignore all the 'other' stuff

noreply@blogger.com (Joe Campbell) — Wed, 02 Nov 2011 02:00:00 +0000

I pulled a quote from this post: http://www.jrothman.com/blog/mpd/2011/06/do-you-have-feature-itis.html

"But with that feeling of excitement must come a feeling of responsibility. Not only is the PO responsible for the product features, the PO is responsible for the business value of the product, and knowing that the team is able to continue to extend the system. Without architecture, tests, all of the necessary engineering practices that good software requires, a technical team cannot deliver."

If you combine the above quote with this talk by Theo Schlossnagle from OmniTI @ the Velocity conference this year I think some interesting things arise.

1) We should as software engineers stop hiding the work we are doing to better the systems we work with from our product owners.

Product owners need to understand the system that they are asking for features in, they have to understand it at a rather fundamental level so that they can treat the software being developed as an asset of the company, as a primary delivery platform. If the Product Owners do not understand their system, they may end up surprised when features that they ask for take a very long time to develop. Understanding the system means that there WON'T be any surprises when the engineers come back with their estimate of how long it will take to accomplish something. If we stop hiding the 'care and feeding' of the system the product owners are adding features too they can be fully informed when they make decisions.

2) It is fine to be the Chief Get it fucking done officer

Provided that you have the ability to both take accountability and to justify what is being done - just GETTING something done is better then talking about it all day long. Sometimes you have to start somewhere just as a way to see if where you are going is either possible or realistic.

3) Being a good software engineer means not settling

When I say not settling I mean, not settling for being pushed into doing a lessor job then you think you should be doing. Most developers that I have run across in my 'shortish' career know when they are taking short cuts and they 'KNOW' when they are hurting the codebase to get an ENDS that is being asked for. If this can never be addressed bad things can happen - and the amount of time that it takes to do development in a given codebase will begin to lengthen till eventually people are calling for a re-write rather than a new feature.

Please POs stop ignoring all the other good things that the developers want to do to help the codebase they work with, please developers stop hiding the work you want to do to maintain the codebase from the POs - development will be a much better place if we can just do this 'little' bit.

The myths we buy into

noreply@blogger.com (Joe Campbell) — Wed, 02 Nov 2011 01:43:00 +0000

Someone I work with posted this link:

One of the more interesting quotes from that article...

"As a boss, your energy has a disproportionate impact on those you lead, by virtue of your authority. Put bluntly, any time your behavior increases someone's anxiety — or prompts any negative emotions, for that matter — they're less likely to perform effectively.

The more positive your energy is, the more positive their energy is likely to be, and the better the likely outcome. "

If you are working under constant and continuous pressure to 'perform' no matter what your position or job, your manager may be making a short sighted mistake where your decision making may be compromised as a result.

Organizational Branching (Feature or Abstraction)

noreply@blogger.com (Joe Campbell) — Fri, 29 Jul 2011 18:12:00 +0000

There has been some recent interesting commentary by Martin Fowler and Jez Humble on the use of features branches in DVCS systems. Specifically Fowler started the conversation with this post on Feature Branches.

It was during my reading of Jez's commentary in his recent post that I had a little light bulb moment about management of organizations in relation to the blog topic.

So the light bulb moment I had related to how companies I have worked for tend to address specific 'project/program' needs within the organization. My observation was this: Companies tend to "Feature Branch" the organization as a way to attempt to accomplish a specific project/program, i.e. new teams or new groups are formed to handle high level work items for the organization.

I believe that organizations run into a great number of the same issues associated with feature branching code when they split their org. structure to do work in this way. Breaking off a new group invites Conway's Law issues and shoves a 'wedge' between the body of the company and this newly formed entity. The new entity slowly stops conversing with the organization - they become disconnected from the needs, the new teams stop being able to really effectively know that what they are developing is helping. The only way to combat this tendency to to have the new org occasionally "merge" what they are doing with the larger organization. If too much time has passed between this merge and the last merge that occurred (Status meeting, conversation or other people synchronizations) then the new team may have developed their software considerably far down a path that is not useful to the organization as a whole - making the merge efforts difficult at best.

Following this analogy I am curious if there is an argument to be made about branching the organization by abstraction, similar to how code might be branched by abstraction. I believe that this would look like having work stories divvied up amongst a bunch of pre-existing teams. Some of the teams may have an expertise in a given area but would be more generalist in nature. This would keep the teams engaged and involved in what the reset of the organization is doing and accomplishing, no thought merging required.

Very interested in any of your (dear readers) experiences or thoughts - this is just something I have been mulling around in my head about how the business of software development works.

Comments...

Carrots, Sticks, Stones and Management

noreply@blogger.com (Joe Campbell) — Thu, 10 Mar 2011 16:15:00 +0000

So - I have been involving myself quite a bit recently with reading and doing presentations to the people that I work with. A recent presentation that I gave was on process and why it matters in the work place. Now - I know what some of you are thinking, NO I have not gone off the deep end and YES I still rail against the Process = Progress models that are occasionally touted by the places I have worked for and "Big Co." in particular.

So - what sparked the presentation in the first place? Well, I viewed the following TED Talk by Daniel Pink on the science of motivation. I also had the opportunity while I was putting the presentation together to read Freedom from Command & Control: A better way to make the work WORK but did not immediately incorporate the ideas of work FLOW from the book into the presentation. Let me focus in on the TED talk as I think it relates to programming.

Carrots

Companies all over the US have been set up for a long time to essentially offer Carrots to their employees. In essence every company I have worked for has a bonus program which is based on some amount of performance that is usually measured by an individuals manager and is more measured by gut feel then by a strict "You got it over the line" type of measurement. Companies attempt to make each "goal" for the year that an individual will do to get their full bonus a S.M.A.R.T. goal - one which is:

Specific
Measurable
Attainable
Realistic
Timely

Which is interesting because it teaches people to game the "Specific" part to be as small as possible so that in the end it is "Attainable". People end up being taught to think IN the box rather then out of it - or risk getting screwed out of the money that they may feel they rightfully deserve. So whats wrong with this Goal/Bonus system?

As Daniel Pink pointed out carrots (Rewards in a do this and I will give you that regime) work very well for anyone not doing 'creative' or 'problem solving' work, in fact they work very well helping people to move faster and do more when the work is easily repeatable or rote in nature.

These types of carrots or monetary incentives however prevent people from being able to use the thinking and creative sides of their mind in order to problem solve. The rewards have a tendency to NARROW the mind which in the end prevents people from seeing more creative "outside the box" type answers to problems. In fact when people were presented problems requiring even rudimentary problem solving skills the time taken to solve the problem increased rather than decreased. Plenty of science to back that up - and yet every company I have worked for still dangles these carrots as if they were something grand and great that you get for working for "Big Co." when really I have come to see them more as a pain in the ass and not as important as the type of work I am going to do or the environment I happen to work in.

Sticks and Stones

A few people have noted to me how much they HATE getting yelled at. For a very narrow band of people the idea of getting admonished by someone is a motivator. I would venture that in today's work place that this behavior by managers or staff isn't tolerated very much at all. I believe that you do still find people that believe that by being an asshole or the office mad man they get results and motivate their people to be better and produce more but I am fairly sure that this only works on people that have fairly low self esteem to begin with, everyone else leaves or quits and goes on to find a better environment or boss to work for and with. Fear of reprisal, similar to adding incentives to creative work, works to de-motivate staff and make them think twice about moving to a new position elsewhere.

What does this all have to do with Management?

Management

Typical management that I have been associated with lives in a world where the hierarchy is king, and their command and control may not really be questioned. The HR department works with management to set up 'Carrots and Sticks' to make sure that workers keep themselves in-line and 'producing' the things that make the company money. The problem is that as software developers we are not building cogs, nor producing cars - we are inherently doing something that requires each and everyone of us to think about what we are doing. We have to spend time asking questions and thinking critically about what we are doing and why. We 21st century workers are much more interested in Autonomy, Mastery and Purpose then we are specifically about the dollar figure. Management has to move to take the conversation about money off the table by paying workers in a way that makes the worker comfortable so that the company can get more performance from the staff and to engage in conversation about the things that really matter when it comes to jobs like software development.

Nothing motivates a software developer better than being told:

1) You have the ability to work when you need to, from home or from the office as long as you get done the work required. Autonomy to work w/ teams in the way that everyone decides rather than in the prescribed way a manager feels is best is a wonderful motivator.

2) Most software developers pride themselves on the Mastery of the software development craft of one or more software development languages. Developers like to share their knowledge with others and take pride in producing cool things that the world uses. Managers should encourage and support this by helping your software development staff to get smart and stay that way.

3) Context is everything. Software developers rail against doing something when they don't have the context for why they are being asked to do it. Not being given this information is a huge de-motivator for most software developers that I know. Context is king and is vitally important to making the software being developed manageable and maintainable over time.

The days of Carrots and Sticks are now done and gone - OH SO 20th century at this point. We need to listen to the science and attempt to find the 21st century motivational equivalents, things like Autonomy, Mastery and Purpose so as to reshape the companies we work for and with and the managers the help run them.

Of Builders, Leaders and Bosses

noreply@blogger.com (Joe Campbell) — Wed, 23 Feb 2011 15:28:00 +0000

I was recently reading a post by Umair Haque on the Harvard Business Review website and to be honest it struck a chord with me.

For the last few years of my career I have been actively working to:

1) Better myself by introspecting on what I am good at as well as listening carefully to the feed back that people and managers I have had are providing to me
2) Change/Effect Change in the places that I work. It is my attempt to make the places I work better for my having worked for them (a workers boy scout rule if you like)

The post stood out to me because, in my own twisted little mind, it put to words exactly what I attempt to be and do when I work for a company. I am not the boss, someone who inspires and instills fear into the people that work for her. I am not the leader, someone who specifically works to inspire. I am the builder, someone who IS inspired to change the world I live and work in, for the better, in whatever way I can.

My desire is clearly present in my relentless effort to get companies to realize that software development is first about the USERS of the tools being built and after that is about HOW the software gets built. I seek to get the places I work for to realize that internal quality is not a compromise that should be made or even can be made in order to get faster. I work relentlessly to get managers to understand that they can dictate or indicate the WHAT of software development but that they should never attempt to control, in the strict sense, the HOW of the software development process. I work to get teams to understand that they can and SHOULD work to change the how of their work each and every day - nothing will get better when the teams just sit idle by and let others tell them how the world should be.

I am a builder - inspired by changing the world (in my own small ways), showing people WHY each and every day - What are you, a boss, a leader or a builder?

JRugged cross post...

noreply@blogger.com (Joe Campbell) — Fri, 10 Dec 2010 18:07:00 +0000

Look ma, I'm Famous. ;)

Xfinity Labs

HttpComponents - Caching Module

noreply@blogger.com (Joe Campbell) — Thu, 02 Dec 2010 15:23:00 +0000

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

noreply@blogger.com (Joe Campbell) — Thu, 25 Nov 2010 02:54:00 +0000

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:

An oil sump that is too small
A quantity of oil that is also too small to dissipate the engine heat appropriately
An originally specified oil filter that is too small to cope with oil sludge that occurs because of 1 and 2
A turbo that can get hot enough to glow with a slight cherry color
Insufficient cooling of the turbo means that engine oil comes in contact with VERY high temps compounding oil sludge issues
Using 'conventional' oil compounds these issues
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

noreply@blogger.com (Joe Campbell) — Tue, 23 Nov 2010 20:20:00 +0000

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

noreply@blogger.com (Joe Campbell) — Mon, 22 Nov 2010 15:12:00 +0000

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

noreply@blogger.com (Joe Campbell) — Mon, 22 Nov 2010 01:19:00 +0000

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)

noreply@blogger.com (Joe Campbell) — Fri, 12 Nov 2010 21:00:00 +0000

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

noreply@blogger.com (Joe Campbell) — Fri, 12 Nov 2010 20:00:00 +0000

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

Critical Thinking

noreply@blogger.com (Joe Campbell) — Fri, 22 Oct 2010 01:03:00 +0000

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

noreply@blogger.com (Joe Campbell) — Fri, 01 Oct 2010 17:52:00 +0000

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

noreply@blogger.com (Joe Campbell) — Fri, 20 Aug 2010 16:31:00 +0000

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

noreply@blogger.com (Joe Campbell) — Thu, 29 Apr 2010 17:11:00 +0000

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

noreply@blogger.com (Joe Campbell) — Mon, 12 Apr 2010 14:22:00 +0000

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

noreply@blogger.com (Joe Campbell) — Fri, 12 Feb 2010 13:50:00 +0000

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

noreply@blogger.com (Joe Campbell) — Tue, 02 Feb 2010 21:24:00 +0000

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

noreply@blogger.com (Joe Campbell) — Wed, 13 Jan 2010 16:19:00 +0000

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

noreply@blogger.com (Joe Campbell) — Mon, 11 Jan 2010 13:50:00 +0000

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.

Agile Scrum / Project Boards

noreply@blogger.com (Joe Campbell) — Sun, 26 Jul 2009 17:00:00 +0000

So, as some of you all may know I am a proponent of agile methodologies. I have posted about agile in the past: here and here and possibly here - what you'll notice about those posts is that they are not specifically about agile, but rather about practices that I find important to doing my job well. This post is specifically about an agile practice and in specific about scrum and the practice of keeping a 'scrum board'

Physicality is king

A scrum amounts to a time boxed iteration of work. In this time box we are fixing the time, the money available (in the form of people) and we are allowing to vacillate the total amount of work that this particular group of people can accomplish (the features they will develop). The team when they start understands how much work they can complete and they commit to doing that many features from a list of features supplied to them. Then the work can begin. This work is 'tracked' as to its done-ness in either electronic form or in physical form. This should come as no surprise to anyone - but I am a large proponent of the physical scrum board.

The scrum board is a physical board used during the iteration to track the work (as mentioned above). Each story/feature gets a card on the board and is placed in the "ready" column. The other columns may vary depending on the team, our team has a "ready", an "in progress", a "done", an "accepted" and an "impeded" column. The cards are placed in each of these states as the feature is being worked on, meets its doneness criteria and is eventually placed into the accepted column.

What is great about this is being able to see and touch the cards or stickies. Doing this provides each team member with a sense of accountability that is not there when you attempt to just talk about features and work you are doing in the 'theoretical' during your scrum stand-ups. Having a physical board provides something that doesn't seem to be there in software solutions either unless you happen to have LARGE touchscreens (think Version One, Rally Dev, etc.) that provide that tactile, walk over and move the 'card' from one column to another, feel.

For me there is also something internally satisfying about really seeing items move from ready, to in-progress to done - Right there on the board. Without it, despite peoples updates, I feel a little lost during the iteration.

Additional (unintentional) Benefits

An additional benefit to the physical board is that is can be a great information radiator - transparent to anyone who happens by... they can see what you are working on, what you plan to be working on and what is already complete just by looking at the board. If an individual needs clarification they can always ask, but the board being out on the floor for everyone to see provides an ave for communication (despite being passive) that didn't exist before. It may generate questions, comments, or just plain discussion. Think about this situation - you are working on a feature in your sprint that interacts with another persons feature set (i.e. more then one team developing at a time) they happen by your board and notice what your team is working on and ask about how its going to integrate with what they are working on. Possible disaster averted due to this simple upfront conversation. Simply AWESOME.

A team can also use the physical board to add additional sprint metrics (information radiation) increasing the transparency with which the team is operating.

I fought the creation of this physical board for our team for a good long time - seeing what it can do to help the team, I am sorry that I fought as long as I did. The physical board seems to be an invaluable tool for the team and the organization at large.

PS: This physical board can also play into a Kanban type pull scenario - but may not include the specific columns mentioned here.

Another Bob Update

noreply@blogger.com (Joe Campbell) — Sun, 26 Jul 2009 16:09:00 +0000

Bob is now home from the hospital and is doing ok. Home care has been arranged for both Mona and Bob so that they have the needed support, at least in the short term for what is going on. There has been a hospital bed and an o2 machine delivered to the home and they are getting visits from the home care people on a regular basis to check up on Bob.

Bob is taking an appetite stimulant in an attempt to get him to eat more (it amounts to refined THC, the chemical in pot)... insert interesting munchies joke here. His intake of food and fluids however is still woefully slight. He is also been taken off the lasiks now that he has been released from the hospital. There is a good chance as well due to his insanely low blood pressure that they are going to remove the need to take his blood pressure medication as well. Which in all honesty is a good thing, one less pill to think about and one less chemical to float around in there. He remains on Plavix to help his circulation. His circulation is also poor and requires him to keep the house a little on the warm side (because he is consistently cold). Mo worked with him to help him layer clothing, etc. to help keep him warmer in his extremities.

This is prob. the last of the significant updates for now unless something bizarre happens or he worsens significantly.

Thank you ALL for your wonderful support, the checkins, the contact and well wishes. It was felt more by myself then it was for mo (as the calls generally came here to the house in NJ) but I will make sure to pass along all the well wishes to her.

People I would never have expected to send their care and good energies have done so in the past two weeks or so. It has been, enlightening and eye opening to me to see that. Thank you all for helping this family with support from yours.

Blessed Be,
Joe