SCNA 2012

I was lucky enough to attend the  SCNA (Software Craftsmanship North America) conference this last weekend in Chicago.  Overall, it was a fantastic experience.

The venue was great.  You really can’t get too much better than the view from the Mid-America club on the 80th floor of the Aon Center:

2012-11-10 16.45.44    2012-11-09 07.52.22

They also did a great job with keeping things short.  Every session was a half hour, with good breaks and interesting lightning talks and games in between.  The format really focused on getting the meat of messages across and limited filler required for sessions in longer time slots. I felt this really helped me not to feel tired (or bored!) and stay engaged and interested throughout both days of the conference.

The conference didn’t focus too much on technical detail, as it’s expected those in attendance are already focused heavily on that aspect. It really focuses on discussions centered around how we can improve ourselves and continue to elevate the standard in our craft.  It was refreshing to attend a conference that wasn’t filled with marketing fluff or heavy technology biases.

I met some good people, had some interesting discussions, learned some new things, and felt rejuvenated and motivated after.   The talks by Uncle Bob Martin and Leon Gersing were highlights for me and gave me a lot to ponder.

All in all, I would highly recommend this conference.

Advertisements

Cleaning the Mess

Recently I’ve had the opportunity to work on a project beginning in a curious state.

An offshore team had failed to deliver and we were brought in by a client to “fix and complete” a rather large code base within a fairly aggressive timeline.

My initial instinct was to treat the code fairly conservatively, to avoid deviating from the existing pattern, get it working, and then re-evaluate, refactor, and clean up the code base.  There was a large amount of copy-paste throughout resulting in a lot of duplicated code. A large portion of the system didn’t work at all and a lot of new code would still have to be added.

My instinct was to treat the system as legacy code, avoid large scale changes until the entire system was well-understood, and apply a “red, green, refactor” type of approach on a larger scale across the system.  We were currently in the “red” state.

I had the opportunity to work with a new team member, @stephenvisser, who was much more interested in approaching the system in a more aggressive manner – do a refactor first, minimize the code base, flush out some reusable components and then make it work.   Initially I was a bit hesitant on this approach given our timeline, as I believed it could cause some up-front re-work of pieces that may have already worked and introduce some risk.

He was quite persistent and we eventually agreed to pursue this direction.  We had a lot of code in need of some love.  A depressing mess.

We started extracting some components, cleaning up existing code, and patterns started to evolve.  Some time passed and we had almost halved the code base, removed duplicate code, and were now progressing much faster with new functionality than could have been possible in the old code base.  It was actually becoming fun to fix old code, often times removing 75% of the mass of a function or class.

I had to concede that although a more conservative approach may have eventually yielded a similar result in the end, we certainly could not have been as efficient – and we would have had to work with a messy, bug-riddled, copy-pasted code base for a slightly longer period of time.

Through working on this project, I started to ponder a few things in more depth:

Forget ego.  Teams need to be able to discuss, debate, and move forward together on solutions.  Don’t get stuck on your initial opinion just because you’ve done it before.  If you’re willing to try an approach that’s new to you, you just might learn something.

Sometimes learning isn’t just about adding new techniques, technologies, it can also be about re-evaluating what you think you already know and learning more about when it’s appropriate.  Sometimes there’s more than just knowing a solution to a problem,  we also need to fully understand the pros and cons and when one method might be more advantageous over another in a specific situation.

Technical debt sucks.  I’ve always been a fan of refactoring after, but refactoring out a mess initially, cleaning house before tackling a problem, can provide immense value. If the code base makes you sad, clean it now.  If you can constantly be proud of what you’re working on, you’ll be more likely to own it and continue working to make it the best you can.

If you’re working in someone else’s mess, it might be easy to find reasons not to clean it… but as professionals, we need to focus on making everything we touch better than it was initially, no matter who created it.  Managers and peers can sometimes underestimate the advantages of clean code, the advantages to maintenance, reducing complexity, and in turn the reduction in the likelihood of bugs.

I for one am enjoying thinking of clean code and our integrity as developers from a slightly more aggressive angle. I always enjoy working with others that bring new perspectives and ideas to the team.  Thanks @stephenvisser for making this project more enjoyable!

Mail Service Refactor Proposal

Everyone who’s every moved knows how unreliable mail can be.

In Canada, if you move, you can tell the post office to redirect your mail for a limited time period so that mail addressed to your old place will be redirected to your new place.  During that time, you are expected to contact everyone who will send you mail and tell them your new address so that after the mail redirect runs out, your mail will continue to find you.  All well and good, but a lot of work… you need to tell the government, get a new license, update insurance, bills, clubs, car service, magazines, etc., etc., etc.  And we know that we never quite seem to catch them all.  When you move into a new place, there is a time period (sometimes years) where you continue to get mail for the previous tenant.

But this is the 21st century.  Why is this so hard?  This system worked OK in the past, but surely we can come up with something better.  We don’t have that problem with email.  Wherever I go, I can get my email.

What if we could improve this?  Wouldn’t it be nice if we could just update our address in one place and everyone who sends mail to us would just get the update?  The truth is, I don’t think that would actually be difficult…

Here’s my proposal:

Imagine that every person just had a number.  Or a unique string of numbers and letters.  When you are old enough to get mail, you sign up online with the postal service, and you are assigned a “Mail ID”.  You are expected to log on to the service and just keep your address up to date.

Every person, company, or entity that can receive mail gets a Mail ID.

If I want to receive mail from someone, I give them my Mail ID.

Let’s say Bob Smith and I are pen pals.  We want to write letters to each other.

I’m going to send the first letter so I ask Bob, “Hey Bob, what’s your Mail ID?”.

He tells me his Mail ID is “123-45678-ABCD”.

That’s all I need to know, and so I start writing my letter.

I put it in an envelope,add the necessary address info (not much), throw a stamp on for good measure, and drop that in the mailbox.

Image

Now, when the post office receives the letter, it scans the Mail Id, looks up the recipients current address and prints it on the envelope below the Mail ID.  Now the envelope looks like this:

Image

Whammy.  Address added to the envelope, postman delivers the same way he always did.

Anything sent to Bob always gets sent to his current address so long as he keeps his address updated.

But the beauty is that there is only one place to update.  Log on to the post office site, update once and you get your mail.  No temporary redirect.  No change of address here, there, everywhere.

You would still have an address.  You can still give that out with invitations to your dinner party.  You just now also have a more reliable (and simpler to update) way to get mail sent to you.

Developer Superstition

Maybe you’ve heard the old “reboot your machine and see if it works”.

I know I have… many times.

Don’t do it. To me this is equivalent to giving up on your problem-solving ability and a potential opportunity to learn something. Basically, “I can’t figure this out. Reboot and maybe it will magically start working.”

Ok, so there’s no real consequence to rebooting your dev machine… but are you going to do this in prod? What if there are other applications on the machine, now all victim to your careless superstition? Computers aren’t magical beings with feelings that affect how they react to input. They’re pretty deterministic, and things tend to be pretty repeatable with a given state and input.

If you wouldn’t do that in prod, then why settle in your dev environment? Take the time to understand the underlying problem. If you understand it, you might be able to prevent it from happening later, in prod, when it matters. Never skip a chance to learn something… and remember that every time you give up and reboot, a very cute and innocent puppy dies.

Don’t get stuck thinking you’re awesome

Occasionally I see software developers referring to themselves as “senior”.  I don’t really like the use of this term too much as I believe it means nothing.

“Hi, I’m a senior developer”

All I heard was “hi”, then some other words, then “developer”.  We don’t need to negotiate status.

Don’t get me wrong, seniority can mean a specific thing inside of an organization – maybe there are pay grades expected by a union or a specific set of expectations and responsibilities that can be divided into different roles. And for lack of creative job titles, we end up with things like analyst I/II/III, or junior/intermediate/senior developer.

But in the context of the industry, or when you are comparing yourself to your peers, what does senior mean ?  Is it how long you’ve been working, or maybe how much you know?  If only length of employment could correlate to competency or if we could measure knowledge, surely we could standardize.  But in an industry as vast as this, we don’t all learn the same things and simply attain different levels of mastery.

If you’ve been a called a senior developer in one company, is it below you to go work as a junior in another company where the bar is set a bit higher?

After some experience and moderate success, it could be easy to start looking around us and think, “surely in comparison to my peers I must be senior”.  After all, they don’t even know what a monad is.  Pfft. Juniors!

But when we think of our level, who should we really be comparing ourselves to?

Why are we comparing ourselves to the programmer who sits in the cubicle down the hall, the crazy DBA, or the guy who doesn’t want to learn new stuff anymore because he’s got it all figured out?

If that’s the standard, then that’s pretty depressing.

We should always be comparing ourselves to some of the more impressive people in the industry.  The ones that did things and made everyone take notice.  The people that changed the way we thought about things or created businesses that forever changed the state of human technology.

People like Alan Turing, Edsger Dijkstra, programmers like Bjarne Stroustrup, Linus Torvalds, or John Carmack.  Or those who are pushing for quality and structure like Martin Fowler, Kent Beck, or Bob Martin.  Let’s not forget those who gave us consumer technology and created industry giants like Steve Jobs or Bill Gates.

When I compare myself to these people, I’ve got a long way to go.  I try to think of myself as just another developer who needs to work at pushing myself to learn new things.  And you can learn something new from anyone — don’t think that you can only learn from people with more experience than you.  Open your mind and just try to get better.  Don’t focus on status or rest on your achievements.   Don’t get stuck in habits just because they worked before.  Continue to self-analyse and observe the way others do things – you just might pick up something new.

There was a great post by Scott Hanselman recently on feeling like a phony and a podcast to go with it.  These described quite well the way I’ve felt and, quite honestly, the way I want to feel.  I’ve learned to accept it.  It’s part of me. Feeling like a phony gives me motivation to keep learning and keep ego in check.

So cheers to the catcher in the rye, feeling like a phony, and trying hard not to be one.

Why should I care about design patterns ?

I’ve occasionally come across developers who believe that the use of design patterns overcomplicates systems and results in code that is harder to understand.  The same developers often don’t know or understand many design patterns; if you were to ask them to name a few, you would most invariably hear MVC and singleton… and then silence.  Prodding for other patterns might result in looks of confusion and an explanation on how they have come to the conclusion that patterns overcomplicate solutions.

What is a design pattern?

It’s often been said that a design pattern is a reusable solution to a common problem.  While this may be true, I think that believing that these problems are too common can be dangerous.  If the problem appears to be truly common, we can be tempted to make a pattern our “golden hammer” — our solution to everything.   After all, we genuinely do want to avoid re-inventing the wheel, which is a good thing… but we have to be careful that we don’t try too hard to force something that is not a wheel to look like a wheel, complicating our original problem in the process.

Attempting to wrap our problem inside of a different, known problem that has a “prescription” will certainly increase complexity.  This could continue to escalate as the original problem is better understood or new features are required and changes to the system are needed to support this.  Will we resist proper refactoring as we try to jam our problem into our “solution”?  We need to take care in ensuring that we understand properly the problem that we are trying to solve.  If it looks like a duck, walks like a duck, but quacks like a pig, maybe the old duck pattern doesn’t quite fit..

In my opinion, an object-oriented design pattern should be thought of an example of solving a specific problem using principles that demonstrate effective object-oriented design.  It should highlight methods of solving specific problems in ways that encourage thinking about good object-oriented principles.  They should hold to ideas like SOLID, a set of principles that encourage us to develop habits toward keeping our systems more maintainable and extendable and more testable.

If we can begin to understand why a pattern is beneficial to a specific problem, we should be able to remain flexible and adapt to unique situations to solve problems in a clean and maintainable way.  We should be able to apply a similar thought process – how can I solve a problem while ensuring that my code is maintainable, extendible, and remains testable  ? I think we should focus more on the why, not so much on the what.  Knowing that MVC stands for Model-View-Controller is much less important than understanding the problem that it tries to address.

So should I create my own patterns ? 

As we continually refactor and apply object-oriented principles to our architecture, along with proper, meaningful naming, the structure of our applications should evolve into local patterns.  These structures can be used throughout a system to keep it consistent where similar behavior is required.  Congratulations, you now have your own pattern – a reusable solution to a problem that is common for you.   It might not be the best solution, and you might think of a better way tomorrow, but you’re now thinking about structure and problem solving at a higher level.. creating adaptive solutions, retaining good programming principles as strange beastly problems come your way.

On the other hand, if we are so lucky to be building a system that addresses some problems that map exactly to a known design-pattern, using these can enable us to communicate through a shared vocabulary.  If we both share understanding of certain patterns, by telling you that my system uses MVVM or uses a factory pattern to create certain types of objects, you can infer a lot about the system and where you could begin to make changes if you needed to maintain or extend the system.   This shared vocabulary allows us to communicate large ideas in fewer words and helps us to understand systems more quickly without examining them in great detail.  When we build systems, we should also consider that we are communicating an idea – how well we can communicate structure has an impact on maintainability of a system.

Conclusion

While it is true that we need to avoid trying to jam our solutions into existing patterns when they don’t fit, this isn’t a good excuse for not learning about them.  I believe that we should be using them as a tool to better understand methods of addressing problems that stay true to object-oriented principles, so that we can effectively structure our applications and apply our own patterns.   Learning about our history helps us to avoid making similar mistakes in the  future.

The danger in focusing too narrowly on existing, common patterns is that we can limit ourselves from thinking about and applying their principles in new ways.  There is no list of patterns that solve all problems for all time, just a few examples from some of those that went before us and wanted to leave us some ideas that worked for them.

So… I challenge you to try to learn at least one new pattern and absorb the reasoning behind it.  You never know when learning something new will come in handy…

New Year, New Blog

I’ve had a shared blog in the past, but as things got busy, we let it slide a bit.  I also started to feel that stepping out on my own and posting my own thoughts would free me from over-thinking the content and how it fit into our combined goals.. and just let me be me and post my own random, incoherent thoughts, for better or worse.

After reading a recent blog post listing 11 things that every software developer should be doing in 2012, and letting it simmer for a while, I decided to resume blogging and try to contribute a bit more + try to challenge myself a bit more in the process.

In regard to the article, I agree with everything said, but I would encourage fellow developers to learn much more than one design pattern at a minimum (and Singleton doesn’t count ;P).  The recommended book is a good start — I’d also recommend checking out something like Martin Fowler’s Patterns of Enterprise Application Architecture . In my opinion, these are not books that I read from cover to cover, but I find I occasionally pick them up when I have a bit of spare time + curiosity to kill in learning something new.  They are also good references to fall back on when thinking about solving a problem, or refreshing your knowledge when you want or need to remember something specific.

Regarding #8 from the blog post, I plan to set some “reachable goals” for myself this year.  I would like to continue to learn to be a bit more intentional in organizing my self-learning.

I will try to post that someday soon to try to keep myself accountable…

Until then, dear reader…