Wednesday, November 30, 2011

Journey of a software craftsman - the backstory

Just as a disclaimer, I want to state my definition of a software craftsman, as someone who recognizes that there is an art, science, and craft to programming and I'm striving to constantly improve towards mastery, knowing that I'm only going to asymptotically approach it. 

So with that out of the way, I'm going to start a small series related to my journey as a software craftsman, finding a mentor, and improving my craft. Before I get to the present, I feel it necessary to record many of the milestones and moments that have brought be up to this point. 

This post is not technical nor specifically related to Flash or Flex, but it does (hopefully) describe the initial part of my journey (before I even recognized I was on one)


  • Mid 1990's
    • Context:
      I was fresh out of school working at a multimedia company. One of our clients used Macromedia Director to deliver their quarterly+ shareholders meetings. This client had a franchise model, and as part of their presentation wanted photos of each of the franchise buildings. Specifically in their "slides" there were 4 photos spots available, each of a different franchise, and as you advanced forward, the photos shifted by one, so that it looked like a single new photo got added to each slide. This is all well and good, but the number and order of the slides changed constantly (even up to minutes before they gave the presentation.) (As I side note, they often took us along to the meeting so that we could update the stock price to literally be the current price when they presented it). Sometimes there would be 100 slides, sometimes only 15. Oh and also their was a print option, which included the scrolling photos as well.

      So basically there was about 150 potential slides, any number of which could be in a given presentation in any given order. Some of the slides had dynamic data, like the stock price, which was updated (manually) all the time.
    • Result
      While it didn't have a name to me at the time, through this project I had already separated the functionality (ordering the slides and photos) from the UI (the next frame and printing) and the business rules (externalize everything to text files (no feasible DB or internet available at the time)). It was my discovery of MVC, nearly a decade before I discovered it had a name
  •  Late 1990's
    • Context
      Many of our projects at the time were training animations with mostly linear controls. I quickly realized that testing the latter parts of the projects was very tedious as you'd have to wait for all of the previous parts to finish.
    • Result
      Modular design. I often rigged in temporary navigation panels, debugging tools, and other test harnesses, to allow me to test faster and more accurately. I was able to pull out the pieces from the rest of the application and exercise them. Nothing automated yet though, not quite. About this time I wrote a utility that would crawl the application display list,  find everything with an interaction on it, and force that interaction to fire randomly. This is the equivalent to clicking everything on the screen as fast as you possible can.

      This is close to automated testing, but it wasn't repeatable, as it randomly choose what to interact with. But while watching it, and the logs, I discovered many many bugs before it went to production.
  • Early/Mid 2000's
    • Context
      I had this intense project where the goal was to fully (nearly) simulate a about to be introduced cell phone (with a camera :) ). The project had a one month time frame, and I had absolutely no idea how to do it. Another motivating factor, was that if we could do it, there would potentially be dozens of more phones to simulate. Since there was only a month to deliver the whole thing, there was a demo every Friday. Without having heard of Agile, I was now in my own self defined agile methodology.  At each demo, we did some planning about what would be delivered the following week. It was at this moment, that I realized that the structure that I had put in place didn't scale, and I wouldn't be able to accomplish next week's goal. I would spend the weekend rewriting everything that I had to support the new objectives. This happened EVERY week. Of course each rewrite / refactoring got faster and better
    • Result
      I discovered Agile. Now it wasn't formalized, as I wouldn't put a name to it until many years later. I discovered the power of short iterations, not designing upfront, the value of starting over with leveraged experience, and refactoring. This was probably one of my most powerful experiences.

      After successfully delivering this project, and the next 2 dozens phones*, I researched how might I do simulations better next time. I came across this book called Flash MX for Interactive Simulation, which talked about State Machines and the State Design Pattern.

      This book opened up the world of Design Patterns and UML to me. The coolest thing, was that my solution for the phone WAS INDEED the State Design Pattern. I was ecstatic and amazed that I had "invented" the exact thing that others were practicing.

      This was incredible fuel to me. I read everything I could about Design Patterns and UML
    • *
      • Phone #1 = 1 month, 
      • Phone #2  =  2 weeks, 
      • Phone #3 = 1 week
      • Phone #4+ = 2 days
  • Mid/Late 2000's
    • Context
      I had the opportunity to be on some teams where there was more then me as the one developer on the team. Some were agile, most were not. I learned the value of source control, integration headaches, testing, and working with other peoples' code. I stated recognizing that code readability was critical, as well as the entire team dynamic, philosophies and varying still levels. (What do you mean you are going to reach up from the child, to the parent, to the grandparent, to another descent and change a property!! #@%! Haven't you ever heard of events? !)
    • Result
      Started on the Pragmatic Programmer and Agile philosophies
  • Late 2000 - Recently
    • Context
      I was on a massive project. Two years, 24 developers. It was huge. I was the Flex technical lead and architect. I had laid everything out (architecturally), both code wise and processs wise. We had a 13point definition of done. But when all said and done the team only accomplished 2 of the 13. We were functionally complete, but we weren't done. Because of several factors, team & management mentality, on-boarding and delegation process... we ended up with what can most easily be described as Legacy Code.

      I tried often to make course corrections to the code base and team, but it didn't happen to my satisfaction. This sent me on a massive effort to try to figure out why I couldn't communicate all of my experience to the rest of my team and what I could do to fix it.

      I devoured references like Working Effectively With Legacy CodeClean CodeClean CoderPragmatic Thinking And Learning, and dozens of other books. I was starving for any information about how to communicate better, clean up the code that was there, help my team improve, and figure out what I did wrong, or what I could do better, either immediately or in the future.
    • Result
      Recognized that I am a software craftsman, but I still have a lot to learn to get to where I want to be. I am actively working towards becoming a craftsman, becoming a mentor, finding a mentor, improving my craft and trying to advocate that quality is important for my industry. 


If you made it this far, thanks for reading my story and sticking around :) I plan on actively contributing to this topic as I continue on my journey. 

No comments:

Post a Comment