Archive for the ‘Software Development’ Category

The Start of a New Quarter

March 7, 2010

This week starts a new quarter at RIT and so I’ll be teaching another edition of SE 361. I love teaching 361. The class moves fast; every lecture is on a different topic.  The course concepts are taught “just in time” for their use by the class.  This week I’ll be teaching on teams, processes and planning.  By this time next week, newly formed teams will have their roles ironed out, team wiki set up and be thinking about the first set of assignments due next Wednesday.  In four weeks there’s an exam, two weeks later the first team presentation, two weeks later another exam, and two weeks later another presentation.  We’ll have covered process, requirements, design, acceptance testing, unit testing, integration testing and UI design issues in the five weeks leading up to the first presentation.  The class moves fast. I feel blessed and honored to be able to influence the next generation of developers.

While I love teaching, I would never give up my day job as a software developer.  I love writing software. I love making these annoying simple, and yet so wickedly complex, pieces of electronics do useful things. I like having a customer come ask me what they think is an impossible or unreasonable task and telling them “sure thing, no problem, I can do that”.  I come from an embedded systems background where we really do make electronics do interesting things, like broadcast and decode radio waves, or spin motors for conveyors…  These days as a software architect my focus is on business efficiencies; integrating various data systems to achieve previously unrealizable operational goals by navigating through the insanely complicated and disconnected operational rules of multiple organizations. While its easy to get lost in the details of the insanity, quality is paramount.  Balancing security with operational requirements and achieving reliable and trustworthy systems… that is what I love to do on a daily basis and that, in a nutshell, is problem solving.

Teaching is not problem solving.  It is a means of sharpening my problem solving skills by trying to be better prepared, more up-to-date… anticipating the next question.  It pushes me to know more about my craft, to reflect on how I perform  it, how do I want to improve it, how can I apply my craft to better achieve my business’ needs. I love teaching, but I’m hard pressed to walk away from the rush of resolving a problem that seemed impossible yesterday and yet now sets the bar a little bit (or a lot) higher for the next problem being sent my way.


The Agile Manifesto

March 3, 2010

I just love the Agile Manifesto. It contains excellent principles for how we should be developing software regardless of what type of development process we are using.  Indeed, I believe that despite its name (agile) we can use its principles in a waterfall situation.  I’m not going to advocate specifically for waterfall, but there are some places that cannot use the more aggressive forms of agile that are so loudly advocated these days.  Waterfall, even with all its weaknesses, will still be a heavily used methodology for many years to come.

I am going to start a series of posts where I am going to discuss each individual principle of the Agile Manifesto.  I’m looking forward to digging into each more directly to see how they fit into my personal philosophies and career experiences and how I think they should be applied in the future.