The Learning Journey

How would it be like if our sales-person shared a few hours of his time acting as an observer on implementing a user story with one of the developers? What if our HR manager set aside a part of her Monday to watch a developer troubleshooting an application or setting up a deployment script?

If software development is at the core of a business (or even if it’s a support function), I would expect that such scheme can help shed a light on how the service is being delivered. It would make it easier for business people to understand what it means when a propeller-head say that “Story X would take Y days to implement” or that “a new release will be deployed to the production server”.

I can understand (and appreciate) that each party has his own value to add to the supply chain. But, sometimes that internal supply chain is taken for granted, and as days go by, everyone starts swimming in his own pond, forgetting that it takes a team effort to deliver quality service.

I’m not sure if such schemes (Business/Developer Pairing) are implemented, but, I would expect it being part of an operations management practice.

Anyone out there?

These images have been glued to my brain since I first saw them. A masterpiece by Jeff Patton that rang lots of bells.

via Obie Fernandez.

via FocusShift

Via reddit, and from there to the best quote I read in a while:”Watching non-programmers trying to run software companies is like watching someone who doesn’t know how to surf trying to surf.” - Joel Spolskey. The quote is highly interpretive, but, to a great extent it bears the truth.

Obie Fernandez, the author of the now de facto Rails book, The Rails Way, have recently launched HashRocket, a Ruby on Rails consultancy with a unique business model:

Your application in 3 days or your money back

OK! That money-back part is of my imagination.

The reason I’m writing this is the “great” message on their homepage.

BUILDING A SUCCESSFUL WEB APPLICATION IS ROCKET SCIENCE

See the word “successful”? It’s a great marketing phrase that reflect how they perceive the value they give to their clients. Delivering a successful web application is indeed difficult, and HashRocket is conveying that message loud and clear.

Congratulations.

This has nothing to do with comparing 8 different frameworks.

It’s just to tell the horror story of one of our down-the-drain projects.

The client came with an old product that he needed to add new features to. The product does, what is best described as CRUD operations. Nothing challenging, nothing difficult. It maintains a set of data for various client in a certain business domain. Their business model (at least what they’re trying to do) is through ad and subscription revenue. They were trying to move the business forward through enhancing the provided service.

The only challenge can best be described as that the product was a pure mess.

It has been built using (last time I counted) 7 different Java frameworks, some redundant, some obsolete. Apparently it has been the greatest learning experience for few individuals. The product took 8 years in the making, 4 different teams (non remained with the project), 14,000+ files, absurdly normalized 100+ tables database, absolutely 0 documents, No unit/function/otherwise tests to reach its current state.

To give some example of code horror that we had to go through, some Java classes contained business logic, HTML code, display logic, data access mechanisms, hard coded urls. The objects were then instantiated from within JSP pages (with lots of other embedded Java business logic/code) and passed parameters and servlet controls.

This is not to mention the build scripts that took 3 hours to update code off of the CVS, then threw numerous errors during the “real’ build.

That’s in addition to the project tree which was in a state of absolute mess (40+ different individual modules, with some exact modules placed in different locations).

And have I mentioned the “wrapper” PHP application that was delivering a CMS-like functionality (another set of mess, with no cross-application awareness of any kind).

Again, the product didn’t do anything challenging. Just basic CRUD and a couple background processes.

Our initial attempt was, of course, to build on top of the insanely absurd code-base, but after few days, we’ve decided (us, client, operations) that it might worth to venture into a new platform, in order to make it easier (and cheaper) to deliver new business service and at the same time, incrementally migrate features into a more robust code base.

Few months into the making; including the client formulating his requirement and reverse engineering the legacy system, we had our first release of the new business features (including the integration with the original application, modelling 70% of the legacy schema, a streamlined version of few original functions, documenting finds of the original application).

Few more months of client acceptance testing (and repetitive requests from our part for a feedback), client vacations, and [seemingly] client running out of budget, the client finally came back to us deciding that our solution was not accepted.

I frankly didn’t know whether to laugh or cry.

Despite the fact that the client admits, in his own words, the original Java application is a bag of “s$%t”, he refuses any attempt from our side to tell him that his application is non-maintainable.

He decided (and probably promised by some other individuals) to monkey-patch the code base that he has. He, of course, threw our choice of Ruby into the bag of reasons not to pursue this further.

Although I can defend our decision to resort to an incremental migration, and taking Rails as our vehicle quite well, yet, I now believe that the choice of technology should be the least of his worries. The business decision of incremental migrations (or even rather a rewrite) remains the optimum choice in my opinion, whether it’s done in Ruby, Java, PHP or brain*^%&.

The moral of the story is: As long as you care, never be a door mat, insist on getting your ideas through, always believe that you’ve been hired not for your typing speed, but for your intellectual abilities and what they can bring to the business.

I just need to get something off of my chest.

Some of the companies that I’ve worked for/with, rely heavily on their clients as the only true measure of performance. They would take client satisfaction as a reflection of how they themselves perceive their operations and businesses.

This is just plain WRONG.

Unless an organization have the established mechanisms and procedures that would identify problems before escalating into “customer dissatisfaction”, then they are on a decline path. Not only they need to identify problems, but, in order to remain competent, they also need to improve their internal operations. This can’t be done if an organization relies solely on their client to tell it how its operations are performing.

I’m not saying the customer satisfaction is not important. All I’m saying is that it should be “A” part of how you measure your company’s performance, not THE measure.

Customers might be pleased with what have been provided to them (in the form of a product/service), but, does that really mean it is the best that could be produced? A customer is never an expert at what an organization does. He’s only an expert at his own businesses/domain. Customers know the little about how a business (other than theirs) is managed, operated and what competitive advantage it has. That couldn’t be more true than in the cases where the traded commodity is as complex as the intellectual ability of an individual/team. In such cases, the only ones capable of establishing those performance criteria are those at the “producing” end, not at the receiving one.

Some organizations go to the uneducated extreme of hanging their employee performance on how their clients perceive those employees (yes, gentlemen, that happens). They sometimes even totally discard what those employees have provided. Their rule of thumb is “as long as there are no complains, they are on the right track”. This can never be furthest from the truth. I’ve been through projects where the products provided are seemingly functional from the outside. But, a simple look at the internals is enough to categorize them as “hit and run” projects.

How does a product/service that is “perceived” to be functional be in such demise? Why?

I belive the answer to the How part is not in the scope of this post (might rant about that in later post), but, I belive that the why answer is simple enough. There weren’t enough “interal” rules to identify what functional/satisfactory is. This doesn’t only apply to the delivered product, but rather the process through which that product was delivered.

In my opinion, the service delivery industry has yet to learn a great deal from the manufacturing industry. Ignoring the current environmental factors; The manufacturing businesses have been through extremes in order to survice and compete, not ONLY by meeting their customers’ needs, but also through the evolution of how they manage their own internal and external operations.

Phew.

Now I can sleep.

Most software development salary surveys I came across are either inaccurate, generic or obsolete. This is an individual effort to capture the pay scale of Canada’s Software Developers & Consultants. It is also an effort to highlight the wide scale of activities usually handled by professionals in the field, which sometimes goes unvalued monetarily or professionally.

Results will be Published periodically on this blog.

Here’s the survey form from Wufoo

Powered by Wufoo