40withegg

I've updated the site's sidebar on the right-hand side of the page with a "Random Blue Top 10 Card" section. Click there and see one of the 74 (so far) "Top 10" cards that I've accumulated since I've been using blue 8x5 index cards to keep myself organized. I'll explain.

For as long as I can remember, I've loved things that organize stuff: tool boxes, personal organizes, PDAs, wallets, backpacks, even those clear plastic compartmentized boxes that fisherman use for tackle. I really like the idea of being organized, but, as it turns out, I really hate actually staying organized. Personal organizers are bulky to carry around and I get tired to opening them, finding the right page, refilling them, etc. PDAs are still clunky, with interfaces that still don't satisfy me. I doubt I'll ever faithfully use a PDA until I can safely stuff it in my back pocket without worry that it will break, or until they are integrated into a flip styled cell phone without losing their usability.

So one day a few years back I was talking to my mother about this problem, and she mentioned that she had become a "list person". She leaves lists for herself all over the place, although she now forgets to take her lists with her, or what the items on the list really mean, and other such age-related fun that I can't wait to experience.

I remembered this conversation one day while wandering around a small mom-and-pop stationary store in San Francisco, and on a whim I bought a pack of blue, lined, 8x5 inch index cards. Over the next few weeks I developed a pretty low-tech to-do list system: I would carry a few cards around, bound with a small binder clip. I'd draw little sections with lists of tasks I'd need to do, and cross them off when I finished them. The most important thing I would do is force myself to write down on the card everything that came up in meetings or conversations that I wanted to follow up upon. Traditionally this has been a bad trait of mine: I forget the little things that I need to do for people, especially when I get bombarded with tasks from every different direction. By writing down everything, even if I've already finished the task, I get the pleasure of crossing it off the list when it's done, which effectively crosses it off of my conscious, too.

Several times people noted that the cards looked like those used by David Letterman for his Top 10 List every night, so naturally I started labeling my cards as my own personal Top 10.

Creating a new Top 10 is a pleasurable ritual that I try to do every Monday. I get a fresh card, write the date on both of the top corners, and write "Top 10" in the middle in some funky text: sometimes it's boxy, sometimes rounded, sometimes normal, but I take my time because it's cathartic for me to dedicate myself, once again, to keeping track of my thoughts.

Week one as a professional agile engineer is over and my head is hurting. Week 1 at any new job is going to be tiring but I think (hey, because it’s happening to me) that it’s even more so when working in an agile software development environment. Pair programming is an intimate thing regardless of how well people know each other, and the dynamics are particularly funky when you’re the new guy. There is definitely a “probing period” – which agile practices do these folks adhere to vigilantly? Which practices do they feel are less important? How do they align with my agile ideology? Do they like curry, and if so, how hot?

Actually, I wish I was an objective observer, watching my own interactions with people I don’t know, because I’m sure I’d be laughing. Agile people, because they want to work closely with others and recognize that interpersonal interactions are important, peculiar, and even fragile, tend to tread gentle steps when suggesting alternative solutions to problems. This tends not to be as much the case after the familiarity barrier is breached.

All in all it was a great week and I learned a lot about Web application design and development. I’m especially impressed by CSS and the flexibility it affords a developer, but I see a potential for a spaghetti mess if developers aren’t careful about reuse, refactoring, and cleanup.

Oh yeah, and the Google Maps API rocks. There are even some “undocumented features” that helps developers find the best map zoom and center point when working with multiple locations on the map. Good stuff.

It is day 2 at my new gig doing agile/XP and Ruby on Rails; my head hurts. I’m trying to wrap my head around the Ruby language, Rails framework, Ajax paradigms, JavaScript, CSS… namely all the stuff I don’t know well.

I had an interesting conversation with several other developers today. We used to all brag about how we had stayed away from “regular” web development for our entire careers. All of us had developed many apps with a Web front end, but for the most part the heavy HTML, CSS, and JavaScript coding was done by people who specialized in that stuff but didn’t know anything about developing applications. We, oh the special “we”, did the real application development, the server side stuff.

But now that’s changing. Lots of back-end, server-side developers are making the move towards Ajax-based application development because it seems to have real promise. It’s unknown just how far you can push it, but now app-only developers are doing full end-to-end development, and we’re hurting. Guess what? This HTML/CSS/JavaScript stuff is hard! And for those of us that are, well, lacking in the graphical design skills, our pages look bad. Thank god for UI consultant.

Right now I’m paring on some rough drag-and-drop-and-resorting problems. I’m in the “point and question” stage of paring, which is always a balancing act: how much do you slow the Driver down to ask questions versus how much to you hope you’ll just start understanding later? It’ll get better as time goes on of course. I should probably start driving so I can get a feel for the syntax, structure, etc.

Twice, when I’ve started a new job, I’ve been put to work on the hardest problem on the entire application. I didn’t know it at the time, of course, but came to realize this later. I’m hoping that it’s happening again.

I’ll describe the modified agile software development methodology which I’ve been using for the last two and a half years. I’ll call it MA for short. MA was far from perfect and was constantly evolving, but it worked on our project. I’m sure I’ll remember more details and update this in the future.

I should note that the products sold by my former company were heavy duty business applications, not web sites. The business problems solved by this stuff are extremely complex: it’ll make your head hurt. One of the major challenges faced by the project was to ramp up an outsourced team of 50 developers on the obtuse business problems as well as the code base. MA made this process less painful.

Major MA concepts:

• 3 week cycles
• Cycle planning with the Planning Game
• Estimation in “points” (nebulous units of time)
• Centralized integration server with serialized integrations. No committing to the repository unless the tests were green.
• Every commit represents a fully functional system
• Update the test server every day
• Unit test the hell out of everything.
• Close relationship with the product managers and other business experts.
• Understand the business domain, not just the technical needs

Agile concepts missing from MA, for whatever reason:

• Pair programming
• A Coach or other technical/process advocate
• Mock objects
• Courage to refactor as needed – stability favored over refactoring

I’ll highlight some of the MA concepts in detail.

Cycles and Cycle Planning

We tended to have 4 releases per year, one per quarter. These releases were broken down into 3 week cycles. This gave us enough time to complete either several small tasks or a couple (sometimes just one) really big task per cycle. It was the developer’s job to break those tasks into smaller pieces, but we estimated them at this larger level.

Our nebulous unit of time was called “points”, and in general developers had about 5 points to spend on tasks. Our product managers were bought in to the point system and were very good at resisting the urge to translate points into days, and thus didn’t drop by exactly when the point-to-days conversion suggested a task should be completed. The developers would estimate all of the cycle’s tasks in points, and product manager would decide which tasks would be worked upon that cycle based on the total available number of points.

Unit Tests and the Central Integration Server

The central theme of MA was our unit tests, which we ran through our centralized integration server. The important details about our integration process are that it was serialized and un-committed: one integration at a time, and code was never committed to the repository unless the tests succeeded. I realize that this is different from many of the “Cruse Control” style integration setups used on many projects today, where developers commit code directly to the repository and hope that the tests run later will succeed. We never did this, and for reasons I’ll describe later I think it was for the best.

Our project had roughly 5000 data-intensive tests – no mock’s here! Integrations took about 45 minutes, where 30 minutes of that was running tests. The remaining 15 minutes was spent checking out code, compiling, shipping the test images to a server farm to be run, etc. I won’t get into the specifics about the integration technology since friends of mine are building a product based on that technology.

The process went like this:

1. Developer is worked on their tasks and wrote lots of tests.
2. They decided it was time to integrate.
3. The developer would add themselves to the “Integration Queue”, which was a list of people waiting to integrate.
4. Once the developer’s name got to the top of the Queue, they would merge their changes with the latest code from the repository. This merge would only exist on their workspace and was not committed. At this point the developer could submit this merged code to the integration server.
5. The server ran all the tests upon the merged code. If everything was successful, the code was committed to the repository.
6. If tests failed as a result of the developer’s new code, they were not allowed to commit their changes. We enforced a “one shot and you’re out” rule, and thus the developer would go back to the end of the Queue if they submitted their integration again. There was an economy here, though, and developers could swap spots in the Queue if they wanted to.

So that’s pretty rigid. But in reality, it’s not so bad when you only have a hand full of developers who know what they are doing, and they are used to the process. But what happens when you drop 50 new developers on the project over night?

Ramping Up the Outsourced Team

Suddenly, our team went from about 10 to 60+ with the addition of an outsourced team in Bangalore, India (BLR). What were some of the challenges?

Our application was weird: I’m sure this is biased, but you can’t get a much harder business realm to learn than our domain. Computer science does you little good on this planet, and it really helps to know why you are being asked to implement such strange features that were often backwards from conventional logic.

Potential for mass destruction: small errors in the application would cause most of it to be completely useless. It had to work as a functional, cohesive system.

We keep our promises: we promised our product managers and QA folks that the test systems would be updated with the latest code every day.

Here is how the MA process addressed those challenges:

Put people on the ground: Ok, this might not be MA specific, but we had people in BLR for a year strait to fully convey the business problems and to teach the MA methodology. I’m sure this would not have worked over the phone. There were technical difficulties, too, which were handled well by having people on both sides of the globe working on the problem.

Non-committing integrations: Since our integrations did not commit code to the repository before the tests ran, nobody could “break the build.” Nobody was frantically email the team with “don’t check out the latest code!” messages.

Test and test and test and test: The BLR team had The Fear put into them if they did not write through unit tests. We, the US based team, would sometimes go so far as to roll back their changes and tell them to commit again after they had more test coverage. Many of the developers had done very little unit testing in their past, having relied on rigorous testing from a fully staffed QA organization. But the team really bought into unit testing once they saw how well it improved their productivity and quality.

Developers wrote the specs: The US developers translated the business specification into technical specifications; BLR would work from these specs. This was a painful doubling of effort but it seemed to work. We would distill the business requirements into a language we would use to speak with other technical people, with a little business explanation mixed in. Eventually the BLR team was knowledgeable enough about the business domain to work with the experts directly, but for a long time developer-to-developer communications were best. Our specs broke the tasks down into chunks that could be more easily estimated.

One day I would love to work with an outsourced team again and evolve the distributed-agile model. I’m sure that I will get chance again.

I rejoined the XP shop in 2003, and though the team was still agile, there was considerably less XP going on. I will post a detailed description of the modified agile process (MA) a bit later.

The project details are most likely forbidden for me to talk about, which is fine. What I will talk about are the areas that worked well vs. areas that needed improvement, from an overall process point of view.

Worked well:

• 3 week cycles
• Cycle planning with the Planning Game
• Estimation in “points” (nebulous units of time)
• Centralized integration server with serialized integrations. No committing to the repository unless the tests were green.
• Every commit represents a fully functional system
• Update the test server every day
• Unit test the hell out of everything.
• Close relationship with the product managers and other business experts.
• Understand the business domain, not just the technical needs

Needed improvement or was missing:

• Pair programming
• A Coach or other technical/process advocate
• Mock objects
• Courage to refactor as needed – stability favored over refactoring

Our project fell into a classic Catch-22: we needed to make technology improvements and refactor/rewrite/toss major areas of our framework, but we had promised business features to paying customers. Needless to say we did not have the bandwidth to do both, but then again, who does? In my opinion, there is where out lack of a Coach-like role hurt the team. Though each member of our team was qualified for this Coach/Team Advocate role, nobody stepped into it, including me. I think the social dynamics would have been a little difficult, if past experience was any indicator. I’ve watched developers move into new roles before and sometimes things get… weird. Feelings get hurt, some egos bruised, and a team funk followed.

So would the Coach/Advocate role have helped the project? Who knows? In theory a Coach would have fought for the development team’s desire to do more refactoring and replace aging and failing areas of the framework. They might have encouraged developers to just do it, refactor, to do what’s right, because they would take the blame if the business folks wanted to kick someone’s butt. Then again, even if the development team had got their wish and had been given the bandwidth to make the needed changes, perhaps the sacrificed business features would have cost us customers.

Now my career shifts once again: I’ve taken a position at an agile software development consultancy. The number one reason why I’m writing all of this down is to remind myself of the many aspects of agile development that I’ve faced over the years, and I’m looking forward to comparing my past experiences with the new ones I’ll encounter soon.

I joined an XP shop in mid 2000, and I was in for a very wild ride. It was quite a shock coming from an insurance company’s cube farm to a cramped, sloping office building with no central HVAC and big trunks of CAT-5 dropping from the ceiling like Half-Life alien traps. But the atmosphere was electric and the people were amazing. I was working with smart people in the XP community and learning a lot about software development projects, and not just from a tech point of view. The business side of the equation also fascinated me, and the dynamics of human interaction present in pair programming was really eye opening. I’ve finally compiled a draft of the “Pair Personalities” after years of pair programming, which I’ll post soon.

For almost a year I did XP to the core: pair programming, cycle planning with task estimation, tons of unit tests, refactoring, and all of the other favorites. But the Dot-Com bubble popped along with my job. For the next couple of years I hopped from gig to gig, and managed to keep my agile mindset intact despite not having much interaction with other agile developers. Here’s what I did to keep the love alive:

Be A Missionary

Several projects upon which I worked did not use a unit test framework, an IDE, source control, or other tools. When I was faced with this unstructured situation I became a missionary not only for agile development, but for good software development practices in general – a voice of reason. Email is not a good source code repository. Testing is good. Databases often store data way better than flat files. Copy-paste coding: bad! Objects are tasty. I always did my best to stay reasoned and logical with people who thought XP was nuts, since they figured I was nuts by association.

Test First Programming

I adopted test first programming on all of my projects. I found that the test would act as my virtual pair when I was programming alone: when I write my tests first, I am having a conversation with it regarding what I should do next, what methods and logic I should implement.

End to End Quickly

I will admit that I have the tendency to get trapped in the details of a feature. In keeping agile I try to steer myself away from this and focus on getting the application I’m writing up and running quickly, UI to database, and as bare bones as possible. Then I try to attach the features one at a time, again being very aware tangent-aware.

Eclipse

I started using Eclipse the day it was announced that IBM donated the project. The tool is amazing, especially the OO concepts, such as many ways in which you can find references to Objects, call hierarchies, and refactoring tools. If only they could keep the Hierarchy view in sync with the editor…

As fate would have it, the company that Dot-Bombed did not Dot-Die, but Dot-Merged with another company in the same business space. I was more than happy to leave the nomad lifestyle and join them again in 2003.

I have been practicing Extreme Programming (XP) agile software development in many different incarnations for 7 years. Sometimes it has been great, and other times it has been more or less imaginary… if a coder practices XP and nobody is around to see it, is he really doing it at all? Here is a brief history of my life as a software developer, with certain names excluded to protect the innocent, guilty, clueless, and paranoid:

About seven and a half year ago I graduated from college with a degree in Management Information Systems. This means that my education was split between business classes and computer science classes, though there was less emphasis on the “science” part. I have never had to write a sorting algorithm, network stack, or slog through many of the other computer science “character building” exercises. I will admit that I’m somewhat of a programming snob, but in the opposite direction than most programming snobs: I’ve never written in C, never thought of VI or EMACS as anything other than a major pain in my butt, and never invented a new distributed file sharing protocol. Hey, I’m not denying that those things would have made me smarter, or that they would have been useful, but there are people way better at that stuff than I am, and they seem more than willing to let me download their hard work so I don’t have to waste my time figuring out my own solution.

I was recruited strait out of college by large major insurance company that had come to a very sobering conclusion: their entire business was built around technology more than 20 years old, people who knew it were starting to retire. They figured that they needed to hire a bunch of young whipper-snappers to infuse the organization with able bodied programmers for years to come. On top of that, there was this new programming language called Java that was all the rage, so teach the newbies that stuff. And that’s what they did.

After a few months of training by expensive consultants, I was dropped into the middle of one of the first major Java projects. I had never done any real world programming and I was pretty freaked out. On top of that, there were these people called “contractors”, and I quickly learn that “contractor” meant “a really smart person that you should listen too because they are super expensive.” Little to my knowledge, the contractors really were top-notch people in the Object Oriented analysis/design world, and in my two years there I was exposed to a series of top level consultants that really new their OO. All of them were from the Smalltalk world, also known as The Language That Kicks Ass Over Whatever Language You Are Using Right Now And Yes, I AM Bitter About It Thank You Very Much.

(As an aside: if you’re ever around some really smart OO minded people, drop a few generic phrases about Smalltalk, such as “This never would have been a problem if we were using Smalltalk” or “It would have been so much easier to do it in Smalltalk” or “Blah blah blah VisualWorks blah blah”. Your OO ranking will go way up in their mind.)

My first programming job at the insurance company was to write JUnit tests. It’s pretty cool to think that in 1998 that JUnit was my first programming framework. But the consultants were tuned in to this weird “Extreme Programming” thing and realized that unit tests were important on many fronts: code quality, documentation, business logic verification, etc. This was great for me from a career development point of view because I had no programming habits yet: I was a blank slate. God, I’m lucky that I fell in with that group rather than the procedural programming group.

After a few years it was obvious that the project was going to fail. I remember laughing out loud while reading The Dilbert Principal, by Douglas Adams: there was chapter about company projects, and the final section was titled “Finishing the Project”, followed by a blank page. That ended the chapter. Anyway, the Dot-Com boom was really, uh, booming, and the XP-minded consultants that had done tours at the insurance company wanted me to bail out and join them at a startup. I did.