Late Night Thoughts on LaSalleMart

This post is one of the 152 I published between 2011 and Feb 2015

Updated Feb 15, 2012

I caught the “Scarborough Fair” scene in The Graduate today, as Dustin Hoffman is driving across the Golden Gate Bridge. With the Academy Awards coming up, Oscar winning movies are de rigour this month.

That long drive over the bridge summed up my feeling today as I dug into Jenkins and builds. A long journey over a very long bridge high above the water. It’s not as if I’m going to make a u-turn, or swerve to the side.


That long drive over the bridge summed up my feeling today as I dug into Jenkins and builds. A long journey over a very long bridge high above the water. It’s not as if I’m going to make a u-turn, or swerve to the side.

If you think CSS is mind-numbing, then you’re really going to glaze-eye on me about software builds. It is uber-geeky. There is no pretense that a non-techie will use it. It’s a journey into geek-land.

Surveying the dev@Cloud Jenkins service, I asked myself “What the hell am I doing?”. I’ve had no occassion to get into this stuff ’til now, so what am I doing here? Can this really be the Moneyball of Joomla ecommerce?

Ladies and gentlemen, it really is the Moneyball of Joomla ecommerce. This is where the techies see real value. This is techie stuff created by techies for techies for the express purpose of creating value in the development process. It’s to make things easier, to avoid doing repetitive tasks, to reduce bugs, to increase the quality of the code, to deploy code.

The thing is, it’s a techie thing. The last thing this part of the techie world expects is “users”. But that’s exactly what we are doing. We, site owners and consultants, are driving our Alfa Romeo’s across that great bridge into the golden roadway to RoI. They are not expecting us there, where the shock on the faces of the techies will be clear on their faces. The last thing they expect here are users from the wrong side of the bridge usurping the very technology that creates immense value for their software development process.

Like many tools of the trade, these tools are FOSS. The Jenkins Server is licenced under the MIT Licence:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software…

Jenkins is available for free to anyone and everyone. It needs a lot of elbow grease though!

Continuous Integration technology used by lowly “users”, put together by lowly “users”, for the benefit of lowly “users”, is the heart of unlocking RoI for us.

And what I thought as I went travelled through software build technology, having crossed the bridge, was that this is a land that we have to live in. And, by living in it, there really is no border between “extension purveyor” and “user”. We are in the extension business, even though we are “users”. So, from code origination to our individual production websites, it’s one big integrated process.

I thought that the demarcation between “upstream” and “downstream” in the software development process is that point where it crosses into the individual website. Ah, but we are the extension purveyor! So, it’s moot. We are Vertically Integrated. We are engaged in all aspects of the software development process. Origination, testing, building, deploying… there’s no “they”. It’s all “we” now.

You know, it takes my breath away. Controlling the code, which is the underlying premise of the GPL, is just part of it. To truly control the code, you have to hold the software development process in the palm of your hand. That means crossing the bridge into geek-land for Continous Integration, the soul of the software development process. does not release software! They deploy continuously, daily:

We don’t really have “releases” because we deploy to production every day – often several times a day. We can do so through our chat room robot, which is the same place our CI results are displayed. We try to make the process of testing and shipping as simple as possible so that every employee feels comfortable doing it.

There are a number of advantages to deploying so regularly. If you deploy every few hours, it’s almost impossible to introduce large numbers of big bugs. Little issues can be introduced, but then they can be fixed and redeployed very quickly. Normally you would have to do a ‘hotfix’ or something outside of the normal process, but it’s simply part of our normal process – there is no difference in the GitHub flow between a hotfix and a very small feature.

Another advantage of deploying all the time is the ability to quickly address issues of all kinds. We can respond to security issues that are brought to our attention or implement small but interesting feature requests incredibly quickly, yet we can use the exact same process to address those changes as we do to handle normal or even large feature development. It’s all the same process and it’s all very simple.

Hotfix is really a Very Small Feature? Well, there is a true understanding where ecommerce profits come from! Profits come from features. Features come from code. That code must actually exist and reside — and work! — on your website. Your focus should be on buying revenue; and, in order for you to buy revenue, you buy features. To buy features, you buy code. Moneyball: You don’t buy players, you should be buying wins. And to buy wins, you need to buy runs. Value is not planning or having star programmers, which are over-valued (Alan will disagree). Value is having real code working for real on your actual website. No technology, no profit! Deploying every day — it’s a culture shock!

The implications! If you deploy everyday, then do you run big massive discrete projects? Wouldn’t we be running a continuous stream of small projects? Wouldn’t we want to run a ton of concurrent small projects? We’d have to find a way to start and finish projects, as we’d be starting and concluding projects all the time.

Theoretically, at least, revenue from the sites under our purview would be growing incrementally, as features were added incrementally every day. A portion of this growing revenue would be, theoretically, re-invested into software development, resulting in more features that create more revenue.

One of the things I learned at tonight’s Toronto Joomla meet-up is that there’s some Continuous Integration skill amongst my Founding Members.

We really are crossing the bridge. No u-turns, no swerving. The technology techies rely on to impart value to their software development process: here we come!

Category: Original-Blog
This Post Has No Tags