I’d like to meet whoever invented the Compiler Warning. I’d punch him.
No individual has done more hidden harm to programming projects than the guy who created the compiler warning. Compiler Warnings are runtime errors that hide from you and laugh at you when you try to find the bug that’s keeping your code from being shipped on time.
Author’s Note: It appears in the conversion from BlogEngine.NET to WordPress the code block was truncated. I have no idea what it used to read; but if I can find it I’ll edit it in. Otherwise, assume it was horrid code.
Recently I was cleaning up some code in a legacy application and found this little gem:
private IList entities = new List
This code was written about 2005. C# had the ‘using’ block, as well as try/catch/finally. But in this case, neither is used to clean up the dataAdapter .
That’s important to know. It’s really easy for me to cast judgement on this code; but what really matters is *why* this code was written the way it was. It’s not as if the people that worked on this application were stupid — on the contrary they were probably quite smart. There are a number of reasons why it was written this way:
Programmer didn’t understand what could happen to the open connection if something failed.
Programmer didn’t realize there was a ‘using’ or ‘finally’ statement in C#.
No Code reviews (or)
No one senior enough to review the code.
There are also some other indicators in the code itself that tell us something about who wrote it: They used comments that explained what we already knew, and they used comments to close blocks of code, both distractions to understanding the code.
There’s a certain amount of ‘If it isn’t broke, don’t fix it’ in legacy applications. There’s inertia against changing code, especially if the code physically works. But the real question is, Should the code be changed? and the answer is unequivocally Yes.
What happens if it bombs when calling FillSchema? What about if the connection to the database dies? What about if it throws an exception for some other reason?
These are all questions we should be asking ourselves when working on code. I hate to invoke Murphy, but if there’s a chance that something can go wrong, it will. It’s our job to make sure that when it does go wrong, we handle it gracefully.
Don’t ever accept We’ve always done it that way as a valid reason to keep code the way it is. Code is a living document, not the Constitution. Treat it as such.
1. From 9 June to 9 July 2006, you should read the sports section of the newspaper so that you are aware of what is going on regarding the World Cup and that way you will be able to join in the conversations. If you fail to do this, then you will be looked at in a bad way, or you will be totally ignored. DO NOT complain about not receiving any attention. 2. During the World Cup, the television is mine, at all times, without any exceptions. If you even take a glimpse of the remote control, you will lose it (your eye). 3. If you have to pass by in front of the TV during a game, I don’t mind, as long as you do it crawling on the floor and without distracting me. If you decide to stand nude in front of the TV, make sure you put clothes on right after because if you catch a cold, I wont have time to take you to the doctor or look after you during the World Cup month. 4. During the games I will be blind, deaf and mute, unless I require a refill of my drink or something to eat. You are out of your mind if you expect me to listen to you, open the door, answer the telephone, or pick up the baby that just fell from the second floor….it wont happen. 5. It would be a good idea for you to keep at least 2 six packs in the fridge at all times, as well as plenty of things to nibble on, and please do not make any funny faces to my friends when they come over to watch the games. In return, you will be allowed to use the TV between 12am and 6am, unless they replay a good game that I missed during the day. 6. Please, please, please!! if you see me upset because one of my teams is losing, DO NOT say “get over it, its only a game”, or “don’t worry,they’ll win next time”. If you say these things, you will only make me angrier and I will love you less. Remember, you will never ever know more about football than me and your so called “words of encouragement” will only lead to a break up or divorce. 7. You are welcome to sit with me to watch one game and you can talk to me during halftime but only when the commercials are on, and only if the halftime score is pleasing me. In addition, please note I am saying “one” game, hence do not use the World Cup as an excuse to “spend time together”. 8. The replays of the goals are very important. I don’t care if I have seen them or I haven’t seen them, I want to see them again. Many times. 9. Tell your friends NOT to have any babies, or any other child related parties or gatherings that requires my attendance because: a) I will not go, b) I will not go, and c) I will not go. 10. But if a friend of mine invites us to his house on a Sunday to watch a game, we will be there in a flash. 11. The daily World Cup highlights show on TV every night is just as important as the games themselves. Do not even think about saying “but you have already seen this…why don’t you change the channel to something we can all watch??”, the reply will be: “Refer to Rule #2 of this list”. 12. And finally, please save your expressions such as “Thank God the World Cup is only every 4 years”. I am immune to these words, because after this comes the Champions League, Italian League, Spanish League, Premier League, etc etc. Thank you for your cooperation.
During the latter part of Basic Training, when the Drill Sergeants stopped screwing with us at every conceivable opportunity, they sat down and talked to us. During one talk, a trainee (we weren’t allowed to be called ‘soldiers’ yet) asked for tips on how to get promoted and on how to ‘get ahead’.
I wasn’t prepared for what the Drill Sergeant said next.
The key to being promoted in the Army is simple: Follow through.
Most soldiers don’t worry about perfecting the fundamentals: Shining Boots, learning their Common Tasks, or any of those other things that make a soldier a look like a soldier. After a soldier graduates from Initial Entry Training (Basic Training + MOS (Job) Training), they are assigned to a unit. At that point, whatever discipline they have is a combination of their supervisor’s dedication and their own. As the Drill Sergeant pointed out to us, it’s that personal dedication to completing a task that separates the ‘ok’ soldiers from the really good ones. The soldiers that shine their boots, keep their uniforms pressed, and look the part end up getting promoted faster in the Army.
The same holds true in Software Development. Very little of our job is actually coding. Most of what we do is spread among various non-coding responsibilities: Managing User expectations, taking responsibility for software failures, collaborating with the users, other development teams, and the QA team. Most software developers are great at being programmers. But when it comes to explaining things in a way a user can understand, we don’t fare so well. It’s bad enough that almost every job posting for a developer includes:
Exceptional verbal and written communication skills. You will need to be able to communicate complex technical concepts to the US and offshore development team, and communicate status, issues, and risks to our leadership team.
We’re so bad at it (collectively) that an entire industry has been spawned to bridge the gap between software developers and business users. You may remember this clip from Office Space:
In a recession, and with the smartestminds believing this is going to turn into a depression, it’s time to move out of our comfort zone and follow through with the non-coding parts of our profession. We don’t have the luxury of avoiding human contact any longer. If you want to be a successful (and employed) programmer, you must learn to follow through. Without that follow through, you may find yourself unemployed or worse, unmarketable.
My mom recently asked me where I’ve been. She keeps up with me through my blog. I’m not sure what it says about me that my family knows what’s happening through my blog more than through me calling them, but I digress.
Twitter is a neat little tool. I like it. I use it as a micro-blogging service, and it gives me a chance to get an up-to-the-minute fix on technology and programming. For instance, in the last week these are some of the items I’ve found on Twitter:
Each week is normally chock full of interesting items and fun items. If you want to learn more about twitter, I recommend reading Brent Ozar‘s book on Twitter: The Simple Twitter Book. He explains twitter much more clearly than I can (just not in 140 characters).
I grew up in a transition period. A period that children didn’t wear bicycle helmets, we played in creeks, woods, and other ‘unsafe’ areas, and apart from bumps and bruises, we ended up just fine. Then something happened. Parents stopped letting children play outside, children wore more padding than a football player to ‘play dates’, and everyone suddenly got more paranoid about safety. Not surprisingly, people still get hurt, maybe even moreso. So it’s a surprise to learn that there is an experiment in place to go in the other direction:
For a number of years now, a number of cities in Europe have been experimenting with the removal of all traffic signs – including traffic lights, stop signs, speed limit directives – and with surprising results. Various towns in the Netherlands, Germany, Belgium, Sweden, New Zealand – even the UK! – have joined in the experiment. Contrary to the expectations of those who might expect multi-car pileups throughout the cities, traffic accidents have been dramatically reduced (in one town, dropping from about eight per year to fewer than two).
The architect of this experiment, the late Hans Monderman, is quoted to have said, “it is dangerous, which is exactly what we want”:
“Unsafe is safe” was the title of a conference held on this practice. Monderman added that this effort “shifts the emphasis away from the Government taking the risk, to the driver being responsible for his or her own risk.” Equally significant, drivers now focus more of their attention on other motorists – taking visual cues from one another, informally negotiating for space, turning into an intersection, etc. – instead of mechanistically responding to signs and electronic machines.
Monderman stated: “When you don’t know exactly who has right of way, you tend to seek eye contact with other road users. You automatically reduce your speed, you have contact with other people and you take greater care.” He added: “The many rules strip us of the most important thing: the ability to be considerate. We’re losing our capacity for socially responsible behavior.” In words so applicable to the rest of our politically-structured lives, he declared: “The greater the number of prescriptions, the more people’s sense of personal responsibility dwindles.” Monderman expressed the matter more succinctly in saying: “When you treat people like idiots, they’ll behave like idiots.” (emphasis mine)
It boils down to this: If you want people to act in a safe manner, remove the safety factor.
For software developers, we’ve heard it in the religious wars between managed languages and unmanaged languages, and in the erroneous assumption that managed languages do not have memory leaks. I don’t have any solutions, although I believe the answer leans towards ‘Unsafe is safe’. Take away the illusion of a safety net and programmers (and people in general) will start paying more attention to their work. You won’t have any C# ‘Slap this together’ apps, but is that really a bad thing?
Captain’s log, Stardate 43539.1. We have moved into orbit around Bre’el IV. With the assistance of the planet’s emergency control center, we are investigating a catastrophic threat to the population from a descending asteroidal moon.” “Captain’s log, supplemental. We are no closer to finding a solution to the deteriorating orbit of the Bre’el moon, but with the arrival of Q we now have a good idea of the cause.” “Captain’s log, supplemental. We have sustained light damage from an attack by an alien species known as the Calamarain. They apparently have a grievance with Q – no doubt one of many lifeforms that do.” (TNG: “Deja Q“)
The Captain’s Log takes you through the high notes, letting you know three things:
What’s happening now
More importantly, it tells you this when it’s happening. Let’s say, God forbid, that Wesley Crusher destroys the ship in a fit of teenage angst and all we find of the ship is the jettisoned Captain’s Logs. Would you rather the last few entries say:
Captain’s log, Stardate 51734.1 “Wesley Crusher has rejoined the ship after an extended stay with the Traveler. In the intervening time, he has grown angrier. Dr. Crusher is relieved to see her son, but concerns about his mental stability remain. I’m asking Dr. Pulaski to run a full scan on him to be certain.”
Captain’s Log, supplemental. “Dr. Pulaski has run the scan, and determined that there is a creature of unknown origin inhabiting Wesley Crusher. In his more lucid moments, Wesley believes he received the parasite during a visit to Risa’s notorious South Pole.”
Captain’s Log, supplemental. “The parasite has taken over Wesley crusher completely, and has used the knowledge of the Enterprise to jettison the Warp core and shut down life support. There is currently no way to get off the ship. This will be my final log as captain of the Enterprise. Her ship and crew have served well, and are in keeping with the finest traditions of Starfleet. I am transmitting this log on subspace Starfleet Command, Priority One.”
Captains Log, Stardate 51734.1 “Wesley crusher came onto the ship today and proceeded to shut down life support and jettison the warp core. There’s no way to leave the ship.”
The first one, of course. It sounds better. it’s more complete, and in case your ship is found adrift with all crew dead, at least someone has an inkling of what happened to you.
Just like in code.
You fix a problem, you go on vacation or win the lottery, or quit. As soon as you step off the plane in Tahiti, there will be a bug with what you fixed. The programmer tasked to fix this bug is going to want to know what you did. He has source control for that; but he’s also going to need to know *why* you did what you did. What alternatives did you consider?
The bug report is your chance to concisely list the relevant issues with a bug, how you are going about fixing it, and most importantly, what didn’t work. Maybe I’m senile, but I can’t remember what I fixed 6 days ago, let alone 6 weeks ago. The bug report helps me keep a running log of what I’ve tried and what I haven’t. In instances where it doesn’t make sense to put it into a defect tracking system, I keep a personal notebook. It goes with me everywhere, and it contains details on any solution I’ve ever tried. It’s my own personal Captain’s Log, and privately I call it that.
If you’re just publishing Changeset numbers and the word fixed in bug reports, you’re doing your teammates a disservice. Programming is hard enough as it is, don’t make it any harder by not ‘showing your work’.
Congratulations! You were just given a new Programmer!
outfit your programmer with the standard office equipment?
order custom equipment specialized for software developers?
ask your programmer what he needs to get his job done?
If you answered (2) or (3), you’re on the right track. otherwise, you get a nice little tombstone when your developers leave, a la Oregon Trail:
Software developers do three things:
Concentrate really hard.
Type a lot.
Sit on their fourth point of contact for extended periods of time.
How does the standard office equipment fare against these requirements?
Poorly. At best.
The monitor is a 15 inch LCD as one screen, and a laptop screen as the second. With any luck it’s a desktop with two monitors, but sadly they’re both 15 inches.
In some unspeakable instances developers have *one* monitor. Prolific developers and bloggers have already beat this subjectto death. To save you time, here’s the right answer: High Quality monitors. At least two of them. Really big ones. Like 24″-30″.
Back to my flattened rear end. Office Chairs are expensive, no doubt. Office chairs that meet our needs? Even more so. I bought a Herman Miller Mirra chair a while back based on recommendations from people I trust, and it’s the best decision I ever made. Believe me when I say that I’m halfway tempted to take it with me to work:
The final piece of the puzzle is a really fast computer. Really fast. Not “Oh, I bought this from Dell” fast, but “We needed to custom order these” fast.
I could spend and entire blog post on that alone (and probably will), but here’s a good rule of thumb: If you can buy it without having to customize it, it’s wrong. Your action word to the Sales rep should be ‘More‘.
Overall, this will cost about $4000 a developer. Another 2-3 grand for the PC. In return, you get a developer who is happier, more productive, and is less likely to jump ship when one of your competitors wises up and starts offering these perks.
Don’t think about it as a cost, think about it as a savings: For any developer you lose, you’re going to lose a lot more than $4000 to replace them.
There are two kinds of companies in this world: The kind that sell you software, and the kind that use software to sell you something else.
There’s also the PGA. Someone forgot to inform them about the technology revolution.
The companies that sell software are easy to spot. You see their products in stores that sell… software. The companies that use software to sell you something are everywhere else. The golfers are on the links, chasing balls and cursing the gods.
Both kinds of companies have a bottom line in mind, they just think there are different ways to get there: Software companies know that good software (or a cornered market) is the key to making lots of money. Those other companies figure that software has something to do with making more money, but aren’t quite sure how that works. They aren’t even sure how to handle software teams.
And you have software developers caught in the middle.
We love what we do. In the majority of instances, we started programming or tinkering with computers when we were young, and it made us happy. We kept doing it. Lawyers can’t file a brief at age 5, but kids can program at age 5. When we grew up, we figured that everyone would see how much we like software and just leave us alone to make it. They had other plans. Meetings, diagrams, excel spreadsheets, quarterly reports, and cost/benefit analyses.
You show them great software, and they want you to make one of those things I just talked about, and try to fit the software in it somewhere, as if it were a line-item on a spreadsheet, or a font of magic in a diagram. In a meeting, it’s just a lot of buzzwords: We’re going to synergize our multiple offerings across the blogosphere with social media while using diverse delivery platforms to ensure a higher conversion rate. Or something.
Then, they pat you on the back, and tell you to go make their dream a reality. Then they leave for the golf-course. You sit down, read through piles of reports, looking at snazzy diagrams, and staring at numbers some accountant told you you’d have to meet.
It’s just about at this point where it hits you: They have no idea what it takes to bring pure thought stuff into something that ships and doesn’t suck. They have the gold, they make the rules, or so the conventional wisdom goes. You start banging out functional requirements, technical specs, and if you’re lucky enough to have a UI guy, he does the user interface stuff, and you two collaborate. If you have a team, you divvy out the work, collaborate on the design if needed, send the questions back to the customer. He’s probably on the golf-course with your boss, or he is your boss.