Agile Teams

Over the past few months, my work scope has grown to encompass a new area: data mining and advanced analytics. As part of my newest project, I’ve been enjoying the opportunity to do some classical and new-fangled data analysis, and some real coding. I’ve written – and tested, and refactored – about 1000 lines of C# code in the last few weeks. That’s nowhere near the amount I used to produce early in my career, but you know what? It’s still fun. 🙂 Anyway, I thought I’d share 3 key observations that have begun to jell as a result of my new work.

1. What’s changed the most are the development tools. Compared to the simple text editors I started with, modern IDEs offer way more built-in guidance and ‘accelerators’ (although they do sometimes get in the way). And I’m learning to leverage the vast amount of online help and forums available nowadays. Learning to navigate the complexities of newer IDEs and debuggers, and become hyper-efficient in using them, will still take a little time, I’m sure.
2. Oddly, the languages themselves haven’t changed all that much. I began with assembler and FORTRAN and quickly moved into RatFor, a C-like Rational FORTRAN preprocessor. I also did some work in Pascal and Ada, and lots of batch scripting, before moving to C and C++, then into Java. Picking up C# over the last few weeks has been straightforward.
3. My background in both agile methods and more formal approaches to architecture and requirements is clearly influencing how I do my work now. Thinking about what might be ‘the simplest thing that will possibly work’ and how to test steers my ‘XP For One’ task planning. I mull up front whether I need to design for performance to handle the huge datasets I’m working with now, and plan spikes to help me test early. For this project, throughput on my laptop is more than adequate so far: my programs runs through 4 years’ worth of data in just a few minutes. Robustness and error detection in how I clean and process my data are critical, though.

Bottom line: it’s gratifying to know that after so many years focusing more on management and process, I do still have the design, programming, and math skills to tackle and solve technical problems hands-on. It’s still cool to wake up in the morning with a piece of a solution to a coding challenge I fell asleep thinking about, or to find my mind puzzling out an answer while I’m in the shower. And I like that this experience is building my mental framework for my future technical leadership, whether in management or coaching or research, to truly understand what product development teams using these latest tools are coping with. It’s all good!