Title
How To: Design and Develop an Application to Ensure its Quality
Audience
AttendeesVictoria University of Wellington, 3rd year “Software Engineering” students (SWEN 301 = COMP 301)
About 30
Date/TimeThursday 14 May @ 4pm
SlidesImpressions
The first half of my presentation, defining and designing quality, was taken straight out of the book. Specifically, straight out of the “Analysing Requirements and Defining .NET Solution Architectures” exam. The second half of my presentation, coding quality, came out of my head and covered training, reviewing and testing.
I could see some heads nodding in agreement as I was speaking, always a good sign. I could see some heads nodding in weariness, never a good sign.
The question time is always my favourite, because it’s then that I can most accurately gauge whether what I have been saying is “scratching the itch” of the intended audience.
The first question was along the lines of “great, you’ve told us some more theory, now what about you personally? What were some of your failures in your career that will help us to avoid pain and embarrassment?” I won’t record here what I told them in answer, suffice to say it amused them..
The PhD student in the audience had come with slightly different expectations. I think he was hoping for more concrete examples of measurements and statistics for writing good code. My rather lame response was that if/when I’m inclined to worry about that kind of thing, then I turn on FxCop to analyse my code for me.
I admitted to being a “lazy coder” in that I enjoy/prefer using objects that I drag onto the page from a toolbox, rather than coding everything by hand.
Definition of terms became important. I needed to very clearly define “Agile” and “Peer”. To me, peer programming is not necessarily the Extreme Programming definition of working side-by-side on the same computer. It just means working as a team on the same project. To me, Agile just means having many, quick iterations, rather than waterfall software lifecycle methodology. I hadn’t realised they considered themselves Software Engineers. To me, there are hardware/network engineers vs. software developers.
EvaluationHi James,
Your presentation today was really good. I believe that students love to have you coming from the really world to share your invaluable experience with them. Thank you very much again for your valuable time and your efforts, in particular while you are so busy. I really appreciate it.
Best wishes,
Dr Hui Ma
Lecturer
Comment by Matt, on 16-MAY-2009 02:31 ( IP: 118.90.5.191 , user id: )
ReplyDeleteHi James,
I was one of the students (right at the back with the Dell laptop if you have one of those photographic memories) that was there for your session, and I really enjoyed it. It's always good to hear from people in the industry as well as learning the theory and applying that theory - one thing I've found with the courses I've done is that they're a little outdated and very 'rigid' in what they teach (you could compare the Uni to the old waterfall model, and the real world to something more 'Agile' I guess).
Having worked as both a project manager and developer (and often both at once on the same project...) I could definitely see bits of what you were talking about during your talk coming up in my work time and again - so it was definitely relevant to me.
Thanks for taking the time out - even if you did get the time paid and a bottle of wine! :P - to come and give us a real-world slant on what we're studying for.
Would certainly be keen to talk more about .NET development sometime as it's something I'm trying to learn (outside of Uni), but haven't had much time to get started at all yet :)
Cheers and thanks again on behalf of all of us,
Matt.
Author's note by JamesHip, on 18-MAY-2009 09:02 ( IP: 146.171.254.66 , user id: 29914)
ReplyDeleteHi Matt,
Yes, I think I remember you. You were top-right (from my perspective) and balanced the MacBook Pro user on my top-left!
Thanks very much for your kind words. They are much appreciated.
I fully recommend you to join the Wellingto Dot Net User Group association. Check out Kirk Jackson's Page of Words blog (http://pageofwords.com/blog/) as Kirk runs the group. Ask to get added to his distribution List, it's worth it. My presentation is precisely the kind of thing the group does each Wednesday fortnight. In addition, there is a Wellington Code Camp coming up in Porirua in June 13-14. Sign up here: http://codecamp.dot.net.nz/. Tell all your friends.
--------------------------------------------------------------------------------
Comment by Rick, on 21-MAY-2009 13:05 ( IP: 203.217.70.251 , user id: )
ReplyDeleteHaving worked alongside real engineers (at Transpower btw) at a formative stage in my early career I can say that there _is_ a difference between the mindset of an engineer and the mindset of most developers.
However, the software developer can adopt the mindset of an engineer, and it will improve the quality of their code. This is a good thing because it means fewer bugs, which means fewer hours spent in debugging (etc).
Adopting the engineering mindset:
(1) More planning
(2) More design
(3) No implicit trust of the code
Because of that last one, it is also sometimes referred to with the pithy catch phrase "Paranoid Programming". In other words, most developers believe that their code is 100% correct (if I had a dollar for every time a developer ha told me "it can't be doing that" after I've shown them some bug in their executing code... well, lets just say that there'd be less of an economic crisis!). And because they believe that, it comes back to bite them later on.
Whereas the paranoid programmer will torture his code to make it give up its secrets. He will also think more about strange error conditions (what should we do if the Database disappears, what if the network connection goes down, what if the user gets halfway through and then wants to quit) and spend time putting in "unnecessary" error handling code. As a consequence, the engineers software will be enormously more robust than that of the developer.
The developer's mindset can be summarized thus: "she'll be right mate".
The engineer's mindset can be summarized as a response to that: "no it most certainly will not".
The funny thing is that it sounds like the engineer will take a lot longer to deliver the first version than the developer because of all the 'extra effort', but in practice I have found the opposite to be true. And even if the developer did by some miracle 'finish' first, they'd be sent back to fix serious bugs after even a modest kicking of the tires by someone else.
When I did Comp Sci they talked about a bug in released software being 10x more expensive to fix than a bug in pre release software, bugs in the design stage being 10x cheaper to fix than once you've started writing code etc.
So the engineer will know that ~an hour spent on planning and design will save himself ~a day of development time later on.
The only exception I have found to this rule is when "fools rush in where Angel's fear to tread". If the situation is so bad that the engineer doesn't even know where to begin.