My first professional software development project in the mid to late 90s involved the following, quite lean process:
All code was written over ISDN, connected to the production server. Tailing the Apache logs in one terminal, ready to save CGI Perl scripts in the other when activity was low enough on the page you where editing.
The first lesson I learned from this was the value of fast feedback. Typing in Emacs over a slow connection is very frustrating. Especially if you just had saved a typo which did bring down an important part of the live site. Surely there had to be a better way?
Prior to this I had written software with myself as the primary audience since around age 8, years surely filled with mistakes as well, but at least I was an amateur.
My first idea of how to solve this problem was to edit files locally, having a personal copy of all source. The primary reason for this was not to have any history of edits - the server was backed up nightly I think, so that's almost a VCS, right - but to maximise my own typing speed, which obviously was the real source of any problems here. If I could just bang out, and fix, code quicker, I would minimise downtime for our customers, and my own frustration (obviously more important here). My main idea of customer satisfaction was to not have people yelling at me over the phone.
At this point, someone in our team, who may or may not want public credit, introduced RCS on the server. CVS was originally built on top of RCS, but RCS itself works on single files at a time. Apart from now having history, and the ability to do very advanced multi-file rollbacks, where no tool came between your memory and change set management, we now had the ability to lock files.
As I, and probably most other people on the team, came from a background where they were the sole editor of code, the idea of collective code ownership was somewhat hazy, but quickly became apparent when your save was followed by someone's swearing across the room, having just gotten their changes lost, which they had been stupid enough to make to the same file at the same time. Pessimistic locking to the rescue.
Well, my - let's pretend I can take some partial credit for this - fight to find a way to edit files locally to minimise the most problematic of programming problems: the cursor is not where you want it to be, and you just typed loads of code in the wrong place, and other, more conservative programmers wish to not have their changes blown away, quickly lead us to the discovery of CVS.
A tool that solves two problems, at once - surely a sign of bad separation of concerns? What would soon come was the inevitable introduction of the dreaded concept of process. Up till this point I had reflected very little over this, my main concern was to get as much cool, working code, as possible, out of the door. This is something I still believe in, but my view of what that means have since become slightly more, let's say, complex.
Actually, I had a brief run-in with process earlier the same year, when I was asked to write an applet for editing document outlines. Somewhere out of the anxiousness over actually being paid to write code, I decided to estimate this to a whole week of work.
I worked on that bloody thing for months, and kept fixing bugs in it for years, even making a grand rewrite, to fix the underlying "design" issues, which lead to even more bugs and incompatibility issues. Out of Fast, Good and Cheap I carefully picked 0 instead of 2. There's surely something insightful to say here about the difference of hacking in a controlled environment, like say on your own Amiga, than on things that get deployed onto all kinds of machines. (I do strongly recommend this book: Racing the Beam - the Atari Video Computer System.)
Here two things happened to me at once. First, I was afraid of being, if not shot, at least fired on the spot sometime during week two. But second, I slowly realised that if there are problems in Microsoft's JVM, which don't arise in Sun's, surely there have to be other paid programmers out there who also made mistakes? And still potentially kept their jobs? Worth mentioning here was that I of course during University met many people who couldn't code even in the CS department, I just - wrongly - assumed they would never be gainfully employed as developers.
I had a vague idea that large companies, like Microsoft, had something called "testers" which somehow were supposed to help with this. We had testers to, our managers and end users. So my next foray into processes, after having mastered the black art of estimating, was bug tracking. We used Bugzilla initially, and even though I was supposedly a technical person, the search screen intimidated me to the extent that I thought it was best to never produce any bugs at all.
DevOps is of course a quite hot topic right now, but the idea that there was any form of separation to bridge was not obvious to me back then. At this eminent level in your career, you fixed the printer, you configured the server and you wrote the code. I won't dig too deep into this, as there was actually this guy who knew unix really well, at least in the context of our team, and he got sucked into doing all this operations stuff. At least I did what sure everyone must do at some point, quickly learning tar, in it's original meaning, tape archiver, after doing rm -rf / half_of_the_system.pl~ as root on the live server.
We were sent to a RUP course around this time, which would fix all these issues for us. This course lasted one whole day and at the end I got a diploma - still the only "certification" in our field I hold. Somewhere here my idealistic young mind started to seriously realise that not all was right in software development: "that course cost us what!?". But it still took a few more years before throwing my hands up in the air and say "damn, all this sucks, it's just money, no love for the art, you fix those bugs while I go off to India!" For the first time.
Up until then I had seriously laughed at the entire concept, even had prolonged fights during billable time, with others about the idea of calling all code in the domain of your choice for "business logic". Surely an absurd concept in it's own right, what's the logic of business? Capitalist blood suckers - the code is there for the people, man!
Somehow this reasoning didn't stop me from believing that Enterprise software sure had to be the pinnacle of refinement, with middleware being the purest of pure, as an enabler for all the other goodness. If I didn't understand it, it had to be cool and interesting, right? Simplicity, and seeing the difference between accidental and essential complexity strangely takes a while and some courage to relearn.
Anyway, then I met a man in a suit who was a "consultant", and knew less than me, who was still in university, about his company's application server. The constant bafflement here is that I just, and to some extent, still, refused to learn that the desire to produce quality work, is not the prime driver for many people's actions.
Which leads me to recall the innocent question, asked a few years earlier when my high school x86 assembler class (I'm not kidding) visited a mobile startup of some sort. My friend asked, in all honesty, this middle manager who did lead the tour, he may even have been the CEO, "but, what do you personally, actually, do here?" The man was stunned, and didn't find any words that could concretely describe that to our young minds.
Because part of this actually takes a while to grasp, as it is - strangely enough - about more than just code. But I'm getting ahead of myself.
Coming up next: discovering XP, and that by writing a specification, like say the EJB one, it doesn't mean that the server you're using will actually do exactly what the specification says. These two themes are closely linked in more than one way. And, does CI stand for Continuous Ignorance?
The title is a reference to John Woo's Hard Boiled, starring Chow Yun-Fat, where the villain, during the final epic hospital sequence, realising that all else is lost, declares that if nothing else, "the innocent must suffer". Which of course they do. **You never know when a degree in Cinema Studies comes handy.