SAIT - Three Inukshuks

Speaking at SAIT today as part of their OOSD Industry Day.  Decided to share three inukshuks (markers) that have been a big part of my 19 year career.

delta - change.  It's a cliche to say that change is the one constant, even more so in Tech.  Still for me it meant that none of the tech that I learned while at NAIT was used in the real world.  OK two exceptions SQL, but that was on a mainframe at NAIT, first used it in MS Access in the real world. C++ but we learned it on DOS and a bit of Windows 3.1 client programing.  First used C++ to write an ISAPI filter for IIS 1.0.

Most of the tech used I've learned on my own.  Java, JavaScript, HTML, Groovy, C#, Mobile development ...

What this means for students: the most important thing you can learn is how to learn.  The best developers have personal projects they use to learn new things.

We've changed they way we think about change.  When I was in school we were taught that we had to get all the requirements for a project up front, and then build detailed pictures of what the code would be, then build the code.

The reason for this was it was much cheaper to find issues sooner than later.    Change was something to be controlled because change was expensive.  There was even this scary curve chart that went with it, showing how latter changes are much more expensive.

When you think about it, that chart is promising to deliver unmaintainable code.  What happens when you need to the code to do new things after the code has been delivered.  That curve says it will be expensive.  Why was this ever considered a good idea?  (That's a very long story that we don't have time for here)

We're starting to embrace change by aiming to keep the cost of change low.  There's a whole fields on this called: Agile Development, DevOps, Continuous Delivery, Lean Development etc.  But at the heart of all of them is the idea that we embrace change by making change easier.

What this means for students: It will depend on what they've been taught, I'm assuming that by now the basics of Agile Development are covered in school.  So we'll see where this conversation takes us.

@ - symbol of email and twitter.  True Story: When we first rolled out new business cards at a provincial department with email address one them we had a director of something barge into the support room and demand:

"What's the public phone number for the email?"

"I'm sorry sir?"

"The public phone number for the email!"

"I'm sorry sir, I don't understand.  Why would we need a public phone number for the email?"

"We have these new business cards, and it list this thing with the @ and it says email.  If I want my email at home I have to dial into our servers to get it.  So what phone number do I give people so they can email me?"

"Oh, no sir.  People will need to have their own connection to the internet through an Internet Service Provider.  They will get the phone number from them.  Then they can email you."

"Well what use is that?  How many people will have that?"

"Last estimate I saw on the number of people connected to the internet was 60 million and growing"

"Oh, realy? Well I guess that's fine."

"Glad I could help sir."

Today Facebook alone has a billion users.  It's a very different world.

What this means for students: Distributed work.  Even if you never take a job where remote work is part of the job description, it may well find you.  When I was with Elluminate most of our team was in the Calgary Office.  We got bought by Blackboard, who also bought Wimba and meged us into one division Blackboard Collaborate.  Wimba was a distributed company.  Most of their team worked remotely.  So our core team that sat together and took out cube walls so we could talk suddenly had to deal with members scattered across the US.

I have one friend who's worked for the same company while living in Calgary, Hong Kong and Hamilton.

Distributed work is the new normal.  Distributed work puts a much higher importance on being able to communicate in writing, and knowing how and when to communicate via voice and video.

The nature of connectivity has changed. We used to dial into an ISP via a phone.  We now have phones that we might make calls on. As an architect I now advise clients to seriously consider a mobile first design for new products.

Mobile is the new normal, and I know when I'm hiring developers I'll be looking for people who understand mobile even if it's not a mobile project.

sigma - symbol for the measurement of the number of defects in the manufacturing industry.

Quality is one of the hardest things to teach in software development.  The term is very over loaded.

There are at least three important quality vectors.

Is it correct?  Does it deliver the right answer, does the right product get shipped?  Does it do the right thing?  This is mostly what gets taught/checked in most courses on software.  Fair enough  it's probably the most important vector.

Is it easy to use?  Usability or user experience design is whole field unto itself.   Still it's worth learning about and thinking about beyond just the end users.  For instance error messages, are they good?  Do the messages work for the user?  Do they help tech support?  Do the help the poor developer who needs to do an emergency fix at 2 am?

When I teach Software Development I give a lecture just on error messages and making them useful for developers.  I had a student at NAIT who was having a problem with a lab.  I looked at the code and looked at her error message and told her to improve the error message and walked away.  Five minutes later she was sobbing.

"What's wrong?" I asked

"I fixed the error message, then it was obvious what was wrong and now it works!"

"Isn't that a good thing?"

"I worked all weekend on this problem, I skipped my daughter's birthday party!  I could have had it fixed in five minutes!"


Is it easy to work with?  Code is the primary design document for your system.  Code doesn't lie, other meta design documents can lie as it's hard and expensive to keep them in sync.  So it's important for code to readable.  It's actually harder to read code then to write code.  And learning to write readable code is very hard.

Having students submit labs that are then thrown away is very different from the real world where you normally have to live with the code you and your team create.   I'm a big fan a labs the build on the previous labs.

What does it mean for students? This part will depend on what they've learned so far, but I'll recommend they learn more about UI design by reading The Non-Designer's Design Book by Robin Williams and learning about Usability Testing from the Nielsen Norman Group.  For code quality, The concepts of Code Smells from the Refactoring Book by Martin Fowler is great place to start.

First Explored Photo of 2014

Millrise Inukshuk is the first of my 2014 photos to make Flickr's explore, if only briefly.

It's also the 6th photo to be added to the Most Interesting of 2014 set.  That means I have enough photos to start using the set to display in the right hand side of the blog.

- Peace