If you liked my post on Is quality really a business decision, check out Uncle Bob’s recent post .
Monthly Archives: October 2009
Thoughts on #RichCC
A couple weekends ago, I attended Richmond Code Camp and had a great time. This was different than the last code camp I went to, in the fact that I spent most of the day presenting, not watching others.
I have coded in front of co-workers before. I have given presentations to strangers before. But I had never coded in front of strangers before. There were a lot of things I learned. Here is a summary of just a few.
Know your audience
One of the two talks I gave was on Powershell. In this talk, I didn’t understand the audience that would be in attendance. I am a coder, not a system administrator. Powershell was designed for both, but a large percentage of attendees were sysadmins, not straight up developers. This assumption caused most of my examples to be irrelevant. Instead of showing how to create a Runspace and call Powershell from within C#, I should have focused more on things like interacting with a database, remoting, and common sysadmin type tasks.
Maybe next time my abstract should be a little more well-defined so that the audience and I are on the same page.
Code very little
In my NHibernate talk, I had about 25 test cases I worked through. Each of those tests started off failing, and required one or two additional lines to make them pass. I would go through each test case, explain what it was doing, why it was failing, and type a couple lines to make it pass. This strategy worked WONDERS!
In my Powershell talk, I tried to code a script from scratch that queried the Twitter API. Bomb. I got so flustered I just copy and pasted from my helper file and made it work. I had to code too much during this demo. Here is my new mantra:
The more critics, the exponentially higher chance of a typo.
(NOTE: Please don’t think I am saying use PowerPoint. Just make it hard for you to screw up the code you have to write)
Figure out how to get some interaction
If you haven’t guessed, I think my NHibernate talk went a lot better than the Powershell talk. One reason I think this is I had almost no audience interaction in Powershell. When I did, they were asking a question that I couldn’t easily answer during my talk. NHibernate had a ton more interaction, and I felt everyone left the room with more info than when they came in.
Wow factor
The wow factor is crucial. Something that is going to make the audience remember your talk.
For NHibernate, the last thing I did was switch my config from MySQL to MSSQL (just the config, no code) and all the tests still passed. Definitely caught peoples attention.
For Powershell, I data bound a WPF app with Powershell scripts. I don’t think it achieved the wow I wanted, but I think its pretty damn cool.
Hanselminutes – Visiting Fog Creek Software
I just listened to the Hanselminutes podcast on Visiting Fog Creek Software. I know it is like 6 months after it was published, but it is a pretty phenomenal podcast. Highly recommend it if you have 30 minutes or so to spare.
If you still have applications written in VBScript, you HAVE to listen (Hint: Joel is running VBScript on .NET…). Also, you get to hear tips on how to become famous (at least nerdly famous like Joel and Scott).
Laptops are confusing…
I recently couldn’t get wireless to find any networks on my work laptop. I contacted our IT Fly Guys and they promptly showed me the wireless switch on the side of the laptop, which I have had for over a year. Needless to say, most of the company promptly received the following email…
Hey team,
Your neighborhood RTS department would like to make a Public Service Announcement. There seems to be a Wireless Switch Fairy floating around the office, turning off everyone’s wireless switch on their laptop.
Please be on the lookout for this Fairy as she has already gotten to one of our most esteemed employees, Brian Hartsock. He was scared, terrified, and completely confused as to what happened to his wireless connection. After some counseling, the RTS dept. was able to calm him down and explain that the Wireless Fairy had gotten to him and his switch. After turning back on his switch, he was able to smile again and become the rockstar he once was.
Once again, please be on the look-out for the Wireless Fairy!! And please console Brian Hartsock if you happen to run into him.
Thank you all for your cooperation in this URGENT matter!
I was even tethering to my phone for internet. I think I need to return my nerd card.
Is quality really a business decision?
A couple weeks ago, I posted my response to Joel’s Duct Tape programmer article. In that post, I linked and quoted an article by Casey Charlton which said that quality was a business decision. I started thinking a lot about that statement, and asking myself the question, is quality really a business decision?
If you are a developer, has the business ever asked you to create a 50% quality product? Has the business mandated that functionality not work 10% of the time? Maybe the bubble I live in at Rackspace shields me from businesses like this, but Pat has never told me to sacrifice quality on anything. In fact, he only expects the results of my work to meet his expectations. He never asks me for code coverage, or code complexity, or any other metric trying to determine the quality of the code. He only asks for results.
Maybe the confusion is over the term quality? There is a difference between functional quality and code quality. I can achieve high functional quality with bad code quality. It might not be easy, but I could hire 2 QA people for every developer and probably achieve it.
The business does directly impact functional quality. If the business is creating the functional requirements, meeting those requirements is functional quality. Those requirements could even seem very technical, like scaling to 100M users, but they are still functional requirements.
Now that we understand functional quality is a business decision, whose decision is code quality? It is a pure engineering decision. Based on business requirements and delivery dates, software engineers determine how to achieve results and how much duct tape to use. Don’t believe me? Read Wikipedia’s definition of Software Engineering (no, I didn’t write it and it is cited):
Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.
The problem is most developers don’t realize this. Instead of trying to achieve both functional and code quality, developers assume a deadline means they should sacrifice code quality. Notice the wording I used, ASSUME. There is no systematic, disciplined, quantifiable approach as to why most developers choose to sacrifice code quality. This is not how engineers are supposed to work.
Think about the parallel of civil engineering. Civil engineers are given a task, like building a bridge. They are also given a budget and timeframe. From there, they determine the materials and methods to use to create a safe structure. They even predicate how long the bridge will last before needing maintenance.
How awesome would it be if software engineers could do the same thing? Software is still such a new practice, we are continually figuring things out, but eventually we will get there. People like Uncle Bob and the Agile Manifesto crew have tried to establish patterns and practices that guide developers based on their experiences.
Quantifying code quality and its impact on functional quality, performance, deadlines, maintainability, and learn-ability is extremely hard. But, we have to strive to understand this information. It will continue to make us better professionals that can reliably accomplish great things.