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.
2 comments:
Thank you for speaking to us. And thank you for posting your notes here.
You have inspired me in several ways. I now intend to focus my learning and effort to improve my ability to do the following:
(a) Design that makes change easier (reduce cost of change).
(b) Design for dominant usage (e.g. today -> mobile).
(c) Design for ease of use (i.e. no user training required).
In addition, I have always tried to write readable/maintainable code that is correct. Correct in the sense of meeting the requirements. Then informing the "release decision makers" about any known deficiencies. However, I want to learn to do this much better.
I intend to start by reading the books you suggested.
I am very interested to hear more from you on these and related topics.
On the issue of documentation. I agree 100% with you that
(i) code is the primary design document,
(ii) meta documents are expensive, hard to keep in sync, and therefore too frequently wrong (wrong implying source of cost rather than savings).
I have always been taught and believed that documentation is a necessary evil. The idea of replacing it with something better is a very liberating thought. Did I understand you correctly, is this what you are saying? Can you recommend any references (in addition to Martin Fowler's Refactoring) that address this issue?
For example, regarding "in-source" documentation and meta design documentation:
(1) What documentation should be produced under what conditions?
(2) Should programmers always look at the source code or are there ways to automatically extract the information they require? Required information such as usage details, inter-"module" relationships, life cycle issues (e.g. deprecation), etc.
(3) What about meta information such as intended purpose, known deficiencies, potential improvements, etc? What information, if any, should programmers make available for other programmers (and probably themselves)?
Thank you again for a very stimulating, thought-provoking, valuable presentation.
Hi Paul. Sorry for the late reply.
The answer to your question is of course it depends a great deal on context. How published is the code, internal IT code vs the JDK code?
In terms of values and where you put your effort first as a default. Code readability is first and foremost to me.
Meta data such as lifecycle etc should be covered in well established patterns of naming and usage. See XP's System Metaphor concept.
My main point in the talk was that documentation in and of itself is not a sign of quality. It may be the exact opposite. Automated build & deploy, automated tests, and great code readability would be much higher on my list of things to look for.
- Peace
Post a Comment