Caffeine Induced

The current project I'm working on is starting to mature to the point where its actually usable (its a Business Process Modelling Tool). Last week we imported/uploaded about 200 MB worth of models from a previous version of the product and it sure uncovered a lot of performance issues. My friend Vince Huston used to always quote : "Make it run... Make it run right... Make it fast... Make it small..." The point he was making is this: Don't cloud your design with premature attempts at things you "think" will be optimizations. I tend to think a lot about usage patterns and scalability during the initial architectural definition phase of the project. Once I feel like we have come up with a solid architecture with respect to the performance/scalability forces, I tend to shift gears and focus more on logical design. When you're fleshing out your vision in a day to day cycle of design / implementation / refactoring, I think its beneficial to the thought process to be able to put the smaller performance issues on the backburner and concentrate on the big picture rather than trying to figure out how you can squeeze the last little bit of performance out of XYZ operation. Delving into some tangental optimization thread of thinking regarding optimization is certainly not conducive to solving the problem at hand (it can be really distracting). Nonetheless, when the time comes for optimization - oh what fun ;). I am an Engineer by training and cut my teeth as a programmer (many years ago) writing C under the 640k barrier. The first few years of my programming career, I used to really take pride in finding obscure ways to represent data structures in a minimal amount of space (you had to be much more space conscious back then). Even now, once I get going on optimization - I become obsessed with it (probably why I try to put it out of my mind until the time is right). Its something I can tinker with for hours on end. I woke up at 3:00 AM this morning with an idea and couldn't sleep until I'd seen how much it improved performance. There's nothing quite as satisfying as cutting a 6 minute operation into 30 second one (and striving after that to cut it to a 5 second one). One of the "Joys of the Craft", in my opinion is when you can refactor an existing solution (that you wrote) into something thats smaller, tighter and faster. Speaking of the joys of the craft, I think one of the things that magnifies and validates this joy is being able to share your daily obstacles and victories with a few close and respected peers. How boring would your existence be if you couldn't bounce a hairy problem off one of your friends or share an exceptionally cool piece of code with them...? This touchs on the XP threads I've seen lately : Rickard, Chiara, Cedric and Crazy Bob have been debating the merits of pair programming. I have never done formal pair programming - I imagine I would have a very hard time with it, as I am very particular about my environment and my conventions (and I would probably have to sit on my hands to avoid having a seizure if forced to watch someone who didn't use an IDE or who was a slow typist). Nonetheless, I have several peers that I respect a great deal that I regularly sit with for intervals when resolving outstanding design issues or particular problems. I remember one 2-3 month timeframe where a friend and I would grab our laptops and go into a big conference room (with plenty of whiteboard) and sit side by side (each with our own machines) and work on the same system. We'd regularly stop and discuss important topics (and draw diagrams on the whiteboard), and occasionaly we'd even sit at the same machine for a few minutes to flesh out a particularly cloudly or difficult area, but once we were both on the same page vision-wise, we'd fan out again (each on our own machines). We regularly reviewed (and used) each others code. I enjoyed it a lot and we were extremely effective in that arrangement - much more so than if we had to share a machine. I think the important thing that comes out of pair programming is communication and review. You can cultivate an environment which promotes these principals without mandating that people program in pairs. For what its worth - I think Cockburn's Agile Software Development Book has some great observations on these things.