Me Program Pretty One Day

Anyone who watches even a small amount of software development is familiar with the scene: The agent, be she new hire or consultant, comes in assuming that success of the project at hand is the goal and that everyone is familiar with its pre-requisites. “Show me to your revision control system” she says.

Cooperative corporate cog that I am, I show her how to get into ClearCase and then explain that most people only check their code in once a week. “How can you build then?” she asks foolishly. I explain that each developer builds locally or on a test VM, but mostly people only build together at the end of the project during the “integration phase”.

Horrified the agent realizes “You’re still using the waterfall model?”

“We prefer to call it the ‘Systems Development Lifecycle’,” someone helpfully informs her.

The false sense of (revision) control

The agent will then hurt herself trying to explain to us what “continuous integration” is. However, ClearCase was designed to stop developers from doing things too continuously, whether it is pessimistic locking or that it takes 20 minutes to check in or check out, continuous isn’t something the developers of ClearCase had in mind.

In addition to ClearCase, there are many horrible and generally expensive options in revision control. The trick is to find the one that takes the longest and asks you the most questions. That will ensure a proper SDLC process. Of course, no one really has time or attention span to answer all of the questions so a Temporal Cold War takes place between the project managers who add new required fields and the developers who learn how enter the minimal number of nonsense characters into those fields so they can “for the love of god check my code in you stupid piece of crap excuse for a revision control system”* (actual simulated quote from a developer forced to use one of these systems).

Our agent begins by trying to “start small” and be a “good example” but is shortly derailed by the fact that it takes too darn long to use ClearCase and checking in or out several times per day would remove all of the time we are expected to spend “actually coding”. While we all knowingly expect her to fail, we pay attention intently because this is the first time we’ve seen a woman who actually works as a programmer who doesn’t come from India or China. The unsophisticated of us assume she got in the field because she wants to date one of us, but the more mature and enlightened are simply fascinated by the spectacle and see ourselves as trailblazers supporting the first American female programmer, or at least the first one we’ve met.

Unsatisfied, our agent becomes “an agent of change” and tries to introduce us to “at least subversion” or “git” if we want to go “faster”. However, we have processes to prevent change. First, she’ll need to get management approval. That will require “a business case” and then she’ll need to “file a change request” with our IT department that will install and maintain the software. While an intern could provision a Virtual Machine and install SVN, an intern would never be granted that kind of authority. Most of all, she needs to convince an IT manager to support her; however, the IT manager is busy trying to figure out why Exchange is delivering only the most important emails 12 hours too late (but spam instantly) and is completely disinterested in anything that would make the developers more productive.

In the IT managers view, the developers are a bunch of pampered whiners who would have his IT department serving them hourly lattes and massages if they had their way. Just last week, one of them even presented something called a PaaS which, among its other downsides, would not require an IT manager.

You shall not pass

Undaunted and still on her quest for continuous integration, the agent begins to talk to us about “unit testing”. We explain that we all agree that unit tests would be a good idea, but management has to be convinced with a business case and reasonable evidence that it would be worth the extra time it takes to create unit tests. She shows us the inevitable chart. (seen above)

She gives us the inevitable statistics, quotes “Code Complete”, notes that even the Department of Defense has turned against the traditional model. We hear about the “Mythical Man Month” and a lot of evidence. However, we explain that management neither believes any of this nor in so-called “global warming” so she’d better come up with some “real evidence”. Management’s logic is based on simple math. Unit tests are not “writing the software they pay us to write”, it takes time to write unit tests, and while we’re writing unit tests we are not “writing the code they pay us to write”. Besides, we have a QA team.

The discussion rages on and we move on to a more interesting tangent as to what is a unit test and what is a functional test. The agent, growing frustrated, tries to explain that it doesn’t really matter in the bigger picture. What matters is that we have tests regularly running in our builds that show us when things break.

Blame by any other name

That brings us to the obvious problem. Her whole philosophy is based on continuous builds. She talks about Jenkins and reads from the prophet Fowler and I helpfully point out that it is lunch time. Undaunted, she continues over lunch. We hear about building branches and tags and other things we don’t use. She starts to get some people to think that maybe some of what she’s talking about isn’t impossible in our organization. I think that by the time lunch is over that she’ll possibly have garnered at least some developers to support her, as little good as that will do her. However, she falters and makes a fatal mistake. She mentions that the continuous integration system can send something called a “blame report”.

Always the gentleman I try to help a lady in distress, “maybe we could call it something else.” However, the damage is done. The support she’d built throughout the day evaporates faster than a pork roast in front of a fat kid. One of the great features of our complicated system of controls is that it is never clear who broke the software or created the bugs. The obvious flaw in her system is that it would give management what they want, accountability.

Build and de(pl||str)oy

Our agent attempts to run our software on her laptop. We bury her in sharepoint resources written on the topic. She works and finally gets all the code checked out and attempts to build. However, our build.xml file was something created by the last consultant that came through our doors. We don’t actually have a “build” so much as we have the IDE to build and package our software.

The agent explains there are automated builds and talks about Ant and Maven and Gradle and Artifactory. We listen, but even she starts to realize that the only way this build will be created is if she tries to accomplish what the last consultant did before we neglected it.

In her report, the agent writes a scathing review of our development practices, quotes Andy Hunt, Martin Fowler, and Steve McConnell until it hurts. We see diagrams and statistics and studies. Most of all we see a follow-on engagement where an army of consultants would modernize us into the new millenium and a few hundred thousand dollars worth of training. I’m sure somewhere in her company a sales guy is slobbering over his steak and budweiser. What he doesn’t realize is that like the flavor of his “grain fed” steak and rice beer, the opportunity doesn’t really exist.

Can’t we buy a product for that?

Then the agent moves on to our architecture. We present to her diagrams from 10 years ago that have never really been updated. We list for her all of the IBM or Oracle products that we’ve purchased to be fully SOA compliant and describe how we are now building our private cloud using their latest offerings. She talks about open source and how the 90s want our Rational Developer Suite back.

Management listens and then I explain to her about “standards” and how our suite of IBM products are made to “integrate” out of the box and “work together”. Sure we don’t know how to use them properly, but that doesn’t mean it is a bad strategy. Besides, we don’t yet own the entire Websphere product line. We’re just a few purchases away from achieving nirvana. At that point the System Architecture team will merely draw our software, a few lines of business logic will be added and WSAD will deploy it to the magic cloud farm in a way that fully supports High Availability and Disaster Recovery. Part of our problem, I helpfully add, is that we haven’t yet upgraded to the latest versions of WSAD and the application server. Perhaps she could suggest that we upgrade in her report.

However, in her mind she has the ammo she needs for her report. She writes about how we can save on licensing costs and how we can have simpler more easily maintained infrastructure. She explains that we’re not really using most of the functionality of the tools we’ve paid for and that the expensive licensing costs and licensing process result in us always being well behind the curve using insecure, buggy, proprietary software.

Dr. Dre and the Aftermath

Our project drags on and becomes later than Dr. Dre’s Detox album. Management ups the pressure and adds offshore resources. The offshore resources apparently are not as disciplined as our team and do not find it necessary to actually attempt to compile any of their code before checking it in. Eventually it is crunch time. That moment where we make it work or find new jobs. We work feverishly, avoid code checked in by the offshore team (which now outnumbers us 3:1) and finally we have a glorious release!

Unfortunately, like most inadequately tested software with poor deployment and revision control practices, our software sank like a rock. It took months to stabilize things while we lost real customers left and right.

Yes we can!

Management brought in a whole team of consultants who shook their heads at what our agent had written. They discovered that the problem was due to the age of the versions of the WebSphere suite we were running. Moreover, by replacing it with Oracle’s suite we’d achieve substantial gains in “developer productivity”. That was an action plan that we could all understand and get behind.

• acoliver's blog