Summary
Motley: Too many assertions make debugging very annoying!
Maven: Lots of assertions are great, as long as they validate the right assumptions. If an assertion fires it is likely manifested by a bug, so get to the root cause and fix it. Best practices for assertions include using them early and often, avoiding executable code within an assertion, and documenting the reason for an assertion.
______________________________
[Context: Motley is having some frustrations while debugging, particularly with components developed by other teams within the company]
Motley: I need to have a talk with the team. Our code has too many debug assertions. They are always firing and it is making debugging very annoying. I constantly have to dismiss the assertion dialog, and when I am executing the same path over and over to debug, it becomes really, really annoying.
Maven: Ah, assertions - one of my favorite topics. I am a huge advocate of defensive programming, and assertions are a great tool. As we have talked about in the past, I like to develop as if the debugger isn't even there. Assertions are mandatory to uphold that way of thinking.
Motley: I still think you're nuts about developing without a debugger. Anyway, assertions have their use, but you can have too many. We do. In this case the large number of assertions is preventing me from getting my work done.
Maven: I am not buying what you are selling. The number of assertions is not the problem. The fact that the assertions are firing on a regular basis IS the problem. In previous teams I have been on, an assertion that is firing that should NOT be firing is considered a priority 1 bug. Think of an assertion as an exception. It is considered a blocking bug from the debugging perspective as you are forcing other developers to continue execution every time they hit it. In addition, assertions validate assumptions, so obviously some assumption is off, which may affect a retail build as well.
Motley: That's true, I guess. I still think we have too many. We probably have one in every 20 lines of source code. And if someone is going to file a blocking bug on me every time they hit my assertion, then I am not sure I want any more than that in the code.
Maven: I would argue that one in 20 may not be enough! Debug assertions are put in place to ensure that you are maintaining a valid state and that your assumptions hold true. Having one in 10 lines of source code may still not be enough. You only see assertions in debug builds, and if the assertions are coded properly, you should never know they are there unless there is a legitimate bug.
Your argument around avoiding blocking bugs is bogus. Code your assertions properly. Give some thought to the conditions. Be thankful if an assertion fires as it is likely exposing a bug in the code. A co-worker gave some great advice around assertions: "If you are assuming anything without verifying it in either the code or an assert, you’re walking a tightrope without a safety net."
Motley: I did learn a little trick for temporarily getting around someone else's assertions when I am debugging without having to rebuild. If there are just a couple that are bothering me, I can disassemble the code around the assertion, look for Int3 which is a debug break, and replace it with no-op byte codes.
Maven: That is very inventive, but make sure you follow up on why the assertion fired in the first place and file a bug as appropriate.
Motley: Another thing to note is that all of this assumes you are running a debug build and not a retail build.
Maven: Absolutely. All of your verification as a developer should be done on debug builds so that you can see the assertions pop up. If you are going to run a retail build but compile only your components in debug, then you may miss some assumptions that were made around your code. You should compile in retail before checking in, but try to do developer validation on a debug build running under the debugger.
Motley: There are ways to misuse assertions too. Regardless of the volume of assertions in source code, here is a list of some stuff I have seen lately in code reviews:
- A developer uses an assertion to check an error condition that is expected to happen. I saw an example yesterday where someone could pass in a bad parameter value to a public API and all there was to protect against the error was an assertion. This will work fine in a debug build, but you are in deep trouble in a retail build. The assertion code will be ignored at compile-time and there is no error check!
Maven: Good one! Assertions protect against conditions that should never happen. They are typically used to check internal state of your classes and invariants (refer to our discussion on design by contract). You still need a construct like exceptions to flag errors at run-time in retail builds. This is extremely important in public methods. In private methods you could get away with just assertions if the method is otherwise protected by public accessors.
Motley: Here's another one I saw last week:
- A developer put executable code inside an assertion. That code will work in a debug build but not in retail. An example like this is bad news:
Debug.Assert(i++ < 100, "Bounds of 'I' exceeded 100");
Maven: Another good one! If that is taking place in a loop, at retail the loop index will not be incremented. Never put executable code inside a debug assertion. Actually, this is a bit of an argument to also do some testing in retail builds as well. To refine my statement above that developer validation should take place on debug builds only, I'd like to resubmit that you should at least run your unit tests on a retail build as well before check-in. You taught me something Mot!
Motley: You act like that isn't a frequent occurrence. Without me around you would probably be on the fast track to nowhere at this company.
Maven: Yeah… right. But I'll humor you. To finish up, here are a few best practices around assertions:
- Use an assertion to protect a switch statement that would not have a valid default case. If you switch on an enumerated type, for example, and someone adds a value to the enumeration and forgot to update the switch, at least you'll find out about it in a debug build provided you assert on the default case.
- Assert even on obvious things. An assertion that may seem totally obvious to you may not be obvious to another developer.
- Assert early and often. The earlier you can validate an assumption in source code the more efficient you will be at finding the root cause.
- Always include an explanatory message with your assertions. Don't just assert without providing justification and/or intention of the condition in the assert. Again, it may be obvious to you but not the next person. What will happen if the assertion is violated?
Motley: You always take a simple concept and blow it all up. I didn't realize there was quite that much thinking behind assertions. They seem like a fairly basic language construct at the high level.
Maven: Yeah, as with many computer science, there may be more than meets the eye. That's what keeps our jobs interesting!
Motley: And overly complicated to the point of making frequent errors producing buggy code and-
Maven: Don't be so negative!
Note: Special thanks to the development leads of the mobile phone and shell teams at Microsoft for their indirect contributions to this blog entry.
______________________________
Maven's Pointer: Think about assertions even at design-time. A design is typically full of assumptions. Document those assumptions at design-time and translate them to source code when implementation begins.
Maven's Resources:
- Assertion-Based Design (Information Technology: Transmission, Processing and Storage) , by Harry D. Foster, Adam C. Krolnik, David J. Lacey, Kluwer Academic, ISBN: 1402080271, May 2004.
- Code Complete, 2nd Edition, by Steve McConnell, Microsoft Press, ISBN: 0735619670, June 2004.
Unfortunately, life got in the way this week and I didn't have time to put together a decent blog entry. Sincere apologies. I'll do my best to have Maven and Motley back next week with their zany adventures in software engineering.
If you have suggestions for future topics you'd like to see covered, or you have any feedback on the blog (good or bad), please do let me know!
Have a good week,
James.
PS. I've been using an online backup service for a few weeks now and have been very happy with it. Check out Mozy (http://www.mozy.com) if you are in need of a similar tool. It's cost-effective, and efficient once you get that first backup out of the way.
Summary
Motley: Management wants clear predictability of all the features we will be delivering in a release. I don't have a crystal ball, and agile removes the need for one.
Maven: Balance long term planning with short term iterations. Agile can play along in a waterfall organization. Use Wideband Delphi to help with predictability of the long term and plan and commit to the high priority features that you have high confidence in delivering.
______________________________
[Context: Motley's team is trying to be agile, but also forced to fit within the model of the overall organization, which isn't agile]
Motley: Ahhhh, the trials and tribulations of trying to be agile in a waterfall world. My frustration factor is above the red line today.
Maven: What do you mean?
Motley: We've been discussing agile development for months now. You know, short iterations, shippable quality at the end of an iteration, frequent retrospection, and all that stuff. So far, it has been working out great on our team, but our company as a whole is more waterfall-oriented. Our team is agile, but Marcus' team is not, and the overall release schedule is waterfall in nature. The management team wants a concrete prediction - no scratch that - a crystal clear picture of what we will be delivering a year down the road.
Maven: Ah, yes. The "crystal ball syndrome". Management wants to know exactly what features are going to ship with the product. They expect detailed estimates that they want the development team to hold themselves to. This scenario is fairly commonplace.
Motley: After practicing agile for a few months, this kind of thinking doesn't seem realistic.
Maven: Perhaps, but keep in mind that Cynthesis also is a business that has to set expectations with marketing, packaging, customers and dependencies. Our partners, for example, are shipping our software on new hardware they are developing and need to have an expectation as to when our piece is going to ship so that schedules can align.
Motley: I guess, but it still doesn't help me predict the future!
Maven: True. We have to balance long term planning (multiple months) with short term planning (a 2 week iteration). Relying exclusively on long term planning is destined to fail as plans always change. Relying exclusively on short term planning does not work for our business.
Motley: It's a no-win situation. I quit.
Maven: I know you are kidding. Trying to be agile in a waterfall world is definitely a challenge, but one that is surmountable.
Motley: The long term plan seems to be a safety blanket for the project. The comfort is not grounded in reality because that long term plan is going to change and we cannot possibly predict all the flaws in the project up front.
Maven: That's where agile comes in. Your long term plan takes the form of a prioritized product backlog (when using Scrum). The keyword here is prioritized. As the environment around you changes, priorities may change, as we discussed previously. There are certain features that you can say with high confidence that the team is going to ship. Communicate these to the project management team. Be conservative. Avoid providing a full plan from the start of the release to the end of the release. And if anyone ever asks you for a Gantt chart depicting the entire release, run for your life. That thing will be out of date before it hits the printer.
Motley: There's still a problem. Even with communicating the inclusion of the top priority items in the release, I still don't have that crystal ball that tells me that I can even deliver those features. We're back to square one.
Maven: Remember we talked about Wideband Delphi (WBD) estimation? WBD is perfect for this scenario. Using a collaborative estimation technique early in the project when there are lots of unknowns gives you a little bit of confidence in predicting how long the top priority features are going to take. We have been very successful using it in the past.
Motley: You still end up with estimates. We still cannot predict the project long term.
Maven: C'mon, Mot. Be realistic here. Of course you cannot fully predict the entire release. Estimation is a fact of life for a development team. There's no getting away from that. What we want to do is improve our confidence for the top priority items and adjust as we go for the lower priority items.
Motley: Oooo, getting a little touchy there, Mave! All that is great, but again, I still have to live in a waterfall world as that's the holistic model for the organization. I have to produce full plans. I have to participate in lifeboat drills where we are forced make hard feature cuts. The organization itself plays schedule chicken rather regularly.
Maven: Let's deal with those things in turn. Regarding full plans, you are going to have to do a high level plan for the release so that you can, for example, predict the number of people needed to deliver the feature set. Plan at a very high level, don't do full investigation of the features, and make sure your prioritization is right for the customer. Communicate this high level plan out to the release manager. Make sure your iterations align with the waterfall-oriented milestones. If the release manager is uncomfortable because there are no details, tell her the details will come on a regular basis as you do your iterations.
Motley: So what you are saying is that we do just enough high level planning to set some core expectations, but we don't succumb to the waterfall model and do an extremely detailed plan complete with Microsoft Project Gantt chart, and instead communicate details as we iterate. Sounds reasonable.
Maven: Precisely. As for lifeboat drills, whereas Marcus' team is going to cut down on features, your team is going to treat it differently. You are going to review priorities of features and ensure your product backlog is stack-ranked accordingly. You can communicate which features you are still highly confident in delivering, and where the cut line is on the product backlog. Also communicate that things may change as you go and you will adjust just-in-time.
Motley: Aren't we still setting expectations about exactly what we will deliver?
Maven: Only for features at the top of the list. The focus is on reviewing priorities.
Motley: That will be a hard one to sell.
Maven: You also used an interesting phrase: "schedule chicken". Can you clarify what you mean by that so we are on the same page?
Motley: The way I look at it, it's like chasing a chicken. You are never going to catch it and always be behind. The management team uses phrases like "creative scheduling". That's just code for fooling yourself that you will meet your dates when it is highly likely you won't.
Maven: Ok. Another variant of schedule chicken is this: I am in a car travelling at top speed towards another car. That second car is the schedule. The contest revolves around who flinches first. I try to force the schedule to flinch first, but it never works out that way and it gets the best of me.
Motley: Nice. I hadn't heard that one before.
Maven: Massaging dates without much rationale is a recipe for disaster. Remember the main project management variables:
- Time
- Features
- People/Resources
- Quality
We never play with quality - remove that one. Releases are often date-driven, so time is static. People and resources are fixed early on in the schedule. Remember, adding people to a late project will only make it later. That means the logical lever to pull is features.
Motley: We buffer the project with scope and deliver more or less depending on the health of the project.
Maven: Exactly. One more thing: a key to making this happen is ensuring you have shippable quality at the end of every iteration. That helps you stay clean and potentially ship at any point in time (this isn't completely realistic on most projects, but is a goal to strive for). By doing that you have more predictability of your long term plan.
Motley: Got it. I also have to make sure I act as the filter for the team and communicate with management in terms that they understand even though we have our own model. I refuse to use Microsoft Project, though, so if that has to happen, it's up to the project manager.
Maven: A necessary evil of being a lead is dealing with a bit of politics. You'll do fine.
Motley: You're having a good day, Mave. All sorts of good advice. Glad to see you've been taking your medication once again.
______________________________
Maven's Pointer: Motley does not have many good things to say about Microsoft Project, but it can be a useful tool when used in the right way. There is nothing wrong with keeping a very high level schedule in Project. List off features at the highest level and milestones that the team as a whole must meet. Individual developers should not be listed on that schedule. Keep the details for your sprint backlogs, if you are practicing Scrum.
Maven's Resources:
- The Mythical Man Month: Essays on Software Engineering, 2nd Edition, by Frederick P. Brooks, Addison-Wesley Processional, ISBN: 0201835959, August 1995.
Summary
Motley: I cannot get management to accept our "new" way of executing. They are stuck in their ways of thinking.
Maven: Change is hard. Do your best to come up with a plan that explains the "why" of the change, enumerates the benefits, mitigates risk, starts small and iterates, presented in a way the management team understands.
______________________________
[Context: Maven manages to catch Motley on his way out the door fairly early in the day. Motley's boss, Mark (director of development for Cynthesis) is the topic at hand]
Maven: I've been noticing that you haven't been working that many hours in the last few days and that your physical self hasn't been in the office as much. Anything wrong? May I help?
Motley: I am just frustrated and, I suppose, lacking some motivation. The team has been doing some great work with agile practices but he is giving us lots of pushback to remain in the waterfall model. The guy just won't accept change. It's his way or the highway.
Maven: I can see how that can get you down. From what I have seen, your team is making terrific strides in quality and efficiency with agile processes. Why do you think Mark is so opposed to agile practices?
Motley: I don't think it has anything to do with agile, per se. I believe Mark is so constrained in his ways. He doesn't want to see change at all. I think Mark is a great guy, but this kind of leadership will doom us.
Maven: Yes, it sure can. Why do you think Mark is so resistant to change?
Motley: I don't know - he's just inflexible. It gets me really angry!
Maven: Let's get to the bottom of it. Here are some possibilities for why people resist change:
- Change is difficult. Mark may be comfortable with his routines. When something has worked in the past, even if it worked minimally well, it's tough to take on something else.
- The change is not understood. Perhaps Mark does not see the benefit in changing his ways. The company may take a hit in efficiency while new processes are introduced. Perhaps Mark does not see long term benefit.
- History is not understood. Is there history that you are not aware of? Have Mark's teams tried agile before and failed? You need to understand his past with respect to the change.
- There is too much risk. Any change plan involves risk. Any change management plan must also include risk mitigation. Mark likely wants to be sure that the proposal will not have long term negative impacts on the business.
- Influence by other factors. The change agent - you - needs to understand how Mark is influenced and tailor your proposal. Perhaps Mark is not as interested in the technical benefits to agile as he is about end value to the business.
Motley: Argh. Why can't he just take my word for it and let me execute? Mark is micro-managing by getting in the way here.
Maven: That may be the case. Ideally, Mark should focus on results and not how your team is getting those results. However, Mark has background as a developer and takes an interest in how the software is built. He is simply looking out for the business. It makes your job a little more difficult.
Motley: No kidding. Unless you have some suggestions for me to try, I'd rather just continue my exit of the building.
Maven: You know me, I always have suggestions!
Motley: I should have known. Stupid me for suggesting otherwise.
Maven: That's the spirit! Firstly, don't give up here. This is a small problem, and I am sure we can bring Mark around to your thinking around agile. I am 100% convinced. Let's start working on a plan.
Motley: I guess you're right - it's a small problem. Wait - did I just say that out loud? Fine. You're right. I owe it to the team to follow this through.
Maven: Excellent. Change is an opportunity to improve, and you are grabbing hold of that opportunity and using it to move forward on the way we engineer software. Here are some steps we can take. Firstly, want to change. Really want to change. This has not been a problem for you, but you need to show that passion when you approach Mark.
Motley: I've really only presented the argument through e-mail, but I guess I should speak with him. Passion does not come across in e-mail.
Maven: That is a great idea - talk to him in person. Next, don't be afraid of failure. One thing that stifles innovation is the attitude that every project - large or small - must succeed. In fact, even those that do not have a permanent benefit are successes as long as you learn from the mistakes and do not repeat them. In Mark's case, if he is afraid of failure, your could start with a small non-critical project. Mark is more apt to say "yes" if failure on that feature will not adverse affect the release of the entire product.
Motley: I have to be clear that only one of our teams is developing in an agile way based on my ideas - okay, with your suggestions - and we could ship without the feature if we needed to. Then I show the success and slowly expand to other teams. I like the approach.
Maven: Sounds like a great plan. When presenting the plan to Mark, make sure you cover why you are making the change. Avoid just trying a new process for fun. There should be some solid rationale for why you are doing it. Present the benefits in terms that Mark understands. If he is quality-focused, show the gains you get in quality. If he is business focused, show him the change to the bottom line. For example, you may ship sooner and the product will be of higher quality with fewer support calls.
Motley: Knowing Mark as I do, even though he has a developer background I need to cover the business issues. The technical stuff generally rolls up into the business anyway.
Maven: Once you are clear on the reason for the change, formulate a plan with risk identification and mitigation. Anticipate the questions Mark will ask up-front. Have answers ready. Show how you will iterate and improve on the execution of the proposal. Present how failure is actually a success but you will do what you can to prevent it. Provide the details Mark will need. Ensure the plan focuses on results. Try to ensure Mark is thinking about results and allows you some leeway in how you produce those results.
Motley: This seems like a lot of work for a small change.
Maven: It really isn't a lot of extra work. You need to go through the thinking around the change anyway. As I said earlier, change for the sake of change is not valuable. Know the reasons for it. The extra work comes into play where you have to present the plan in a way Mark understands and appreciates. It also helps to get others on board with your proposal before you present. These people can help be a proponent for the change and put out any issues. If Mark is influenced by number of people already on board, this can help your case.
Motley: Okay, okay. I'm heading back to my desk. I will work on a plan right away. I guess we have a bit of an advantage here in that we have been doing agile for a while under the radar. We have already seen some success and I can point to that.
Maven: Sure, but be careful. You may have to play some politics here. If Mark is the type of person that gets upset when people do things he is now aware of, you may hurt your cause instead of help it.
Motley: Let me mull that over...
______________________________
Maven's Pointer: As Motley eludes to above, sometimes it's better to ask for forgiveness than permission. When the change is small and generally inconsequential to upper management, often the best approach is the Nike approach: "Just do it." If the change fails, learn from it. If the change succeeds, use it as starting point to bigger and better things and communicate your success if the company culture warrants it.
Maven's Resources:
Summary
Motley: There's not much to public speaking.
Maven: Public speaking requires a lot of practice and know-how. Have a good objective, know your target audience, set expectations, use minimal slides as a visual aid, practice, use a summary, and work on your bad habits. Above all, be passionate about your topic!
______________________________
[Context: Motley has an upcoming presentation and is lacking some confidence around his presentation. He seeks out Maven for a few tips.]
Motley: Didn't you say that James did a public speaking gig at a conference a while back? I was nominated at this special interest group I belong to do a talk on being an effective development lead. I was hoping I could get some tips since I haven't done a lot of public speaking, and generally dislike it. It's a necessary evil, however, to move up the career ladder.
Maven: YOU are giving a talk on being an effective development lead??? That's the funniest thing I ever heard!
Motley: <pow>
Maven: Ah, crap. That hurt! I guess I deserved it though. I apologize.
Motley: Anyway, I'm looking for some tips on doing a good developer presentation. Although there isn't much to public speaking generally, developers are a tough group to keep engaged. Most talks that I go to simply end up helping me catch up on some sleep.
Maven: Doing any kind of public speaking is difficult, and an activity that most people dread. There are some fundamental tips that you can follow, however. The first big tip is to tell them what you are going to tell them, tell them, and then tell them what you told them.
Motley: Come again? That sounded like gibberish.
Maven: Think of it like this: you want to set expectations with audience as to what you are going to talk about. Then you want to provide them with all that wonderful content. Finally, you want to review the key points of what you just talked about as reinforcement, and provide a specific call to action list to help them change behavior once they leave your talk.
Motley: That seems like an awful lot of redundancy.
Maven: In a 90 minute talk, it's not. Hey, that rhymes! I'm a poet and I didn't even know it!
Motley: Oh, dispense with your horrible humor and get to the point.
Maven: You want to prevent wasting people's time, so you talk about what your objectives are, the order of topics (i.e. agenda), and what you hope to accomplish. From this , the audience can determine whether they will get something out of your talk. You don't want to waste people's time if it doesn't meet their expectations. You want to repeat the message at the end so people remember what you talked about. Repetition helps the memory.
Motley: Okay, makes sense. Agenda/expectations, content, summary.
Maven: Don't forget objectives. Think about what success looks like for your talk. What do you want people to take away? What behavior do you want to change? A good talk has objectives that are action-oriented phrases that describe a change in behavior.
Motley: I think I have that covered. I'm a little concerned about fitting 60 slides into 60 minutes. Might be a bit too much. What do you think?
Maven: Too much?!? Definitely! You want to count on about 3 minutes per slide on average. You also want light slides - a maximum of 6 bullets per slide, if bullets are your style.
Motley: Three minutes per slide?!? That means only 20 slides for 60 minutes! I am going to finish really early. I have some slides in there that take only a minute, such as title, objectives, and agenda.
Maven: Remember that 3 minutes per slide is an average and only a guideline. It also depends on your presentation style. If you go with pictures and stories instead of bullets and text, you may flip by slides quickly and your average may be 30 seconds per slide. More dense slides, like your slide on career development, may take you 5 minutes or more to discuss. Make sure, too, that you leave time for questions. Questions must factor into your overall time estimates. For a 60 minute talk, for example, you probably want to leave at least 10 minutes for questions.
Motley: Wow, if I actually decide to take your advice, I have some rework to do. I'm afraid to ask, but any other tips?
Maven: One big one is to not use your slides as the primary focal point for the presentation. Your slides should be a visual aid. Don't read from your slides. In addition, break up your presentation so the audience is not staring at your slides the whole time. Include a demo, video, or audio file to break up the presentation. When you show code, for example, don't just paste it on the slide. Show the code in Visual Studio, compile it, and run it.
Motley: I've got a pretty slick demo of a tool I can show. That's actually a good suggestion.
Maven: Of course it is! Here are a few other tips I've picked up along the way:
- Know your target audience. If you are explaining how a feature in your product works, the technical details in a presentation to a bunch of marketing people and product planners will be drastically different than a presentation to a test team or a group of developers. Guess which one delves into more depth in technical details.
- Include an appendix in your slide deck containing content you cut and/or answers to anticipated questions. Hide the slides in PowerPoint so that they do not show by default.
- Practice, practice, practice. The key to a great presentation is preparation and practice. Do a dry run in front of some people that can give you some candid feedback. At the very least, stand in front of a mirror and practice yourself. Make sure you time the presentation. PowerPoint has a nice feature to "Rehearse Slide Timings" as part of the slide show options that will time not only your presentation as a whole, but also how much time you spend on each slide.
- Make your slides available before the talk. Allow the audience to follow along with the talk and print copies if that makes them more comfortable. Printed copies, or copies inserted into Microsoft OneNote, allow for efficient note taking.
- Set up well in advance of the talk start time. Show up at your talk at least a half hour before the scheduled start time. Make sure you are comfortable with the room, the controls in the room (e.g. lights) and that your laptop (if applicable) is set up correctly. Turn off Messenger and Outlook and any other distractions. Make sure demos are loaded and cached.
- Take care of bodily needs ahead of time. Don't forget to go to the bathroom and grab a glass of water. Once the talk starts, it's too late - unless you want to embarrass yourself of course.
- Take a few deep breaths before you start. Deep breaths will help you relax and calm your nerves. Some people say you should picture the audience in their underwear to calm your nerves. That never works for me, though. Nice skivvies, Mot.
- Maintain eye contact. Make sure you give equal attention to everyone in the room. Maintaining eye contact keeps them engaged. When answering a question, address part of the answer directly at the person who asked the question, but float around to other parts of the room for the rest of the answer.
- Avoid "bad habits". You may not even realize what your bad habits are. Record yourself with a video camera and look for "ummms", "you knows" and the like. You will likely be amazed and appalled at what you observe.
Motley: Lots of stuff to remember.
Maven: One more big tip: above all, be passionate about your topic. Passion can often make up for your lack of skills as a PowerPoint designer and/or a speaker. Be genuinely excited about your topic. You will keep the audience much more engaged than a boring, monotone speaker that cannot excite the audience.
Motley: You know me - no problem there. Sometimes I have to hold back. I will throw in some "colorful metaphors".
Maven: Be careful. If that helps your audience identify with you, then great (although better safe than sorry). If you are talking to a religious group, they may be offended. Know your audience.
Note: "colorful metaphors" is a term I remember from Star Trek IV when Captain Kirk was describing the earth culture of blasphemy to Mr. Spock.
______________________________
Maven's Pointer: James didn't realize he had a very bad habit when teaching classes at Microsoft. He tended to move around A LOT, and when watching himself on video he could tell how annoying must have been to attendees. He needed both the video and a presenter trainer to point out this habit. Now he is conscious of it and does his best to keep himself anchored to something and move with purpose.
Maven's Resources:
- Beyond Bullet Points, by Cliff Atkinson, Microsoft Press, ISBN: 0735623872, October 2007.
- There are hundreds, if not thousands, of books out there on presentations. One of the best resources, however, is to find a speaker you admire and learn from them. At Microsoft, Steve Ballmer is a very dynamic speaker who is extremely passionate about his topic. Some people love him, some people dislike him. Although he may break many presentation rules, I find him extremely engaging as a speaker and he is someone I like to learn from.
Summary
Motley: Native C++ code development is obsolete. Everyone should be using a language like C# or Java.
Maven: Managed code is a great platform, but there are still reasons to use native C++, such as enhancing legacy code and developing an operating system (e.g. Windows Mobile). Understanding C++ makes you a better managed code developer.
______________________________
[Context: Maven and Motley are in the middle of discussing programming languages and, in particular, C#. Motley is pondering other languages and their usefulness]
Maven: I agree with you Mot - C# is a killer language. There are constant strides to move it forward and it is very intuitive for a new developer to learn.
Motley: I wouldn't want to develop in any other language, thank you very much. In fact, I am surprised other languages still exist. Well, Java has a place for the non-Windows developers, but other than that, why maintain them?
Maven: C# is great, but there are other languages out there that are still widely used. C++, for example, is still used in many different companies and serves a real need.
Motley: Hah! Name one. There are so many advantages to developing with managed code that you don't get in C++. C# is much more intuitive and easier to learn than C++. It is harder to make nasty mistakes considering you have garbage collection. Exception handling is a built-in construct. Your code is optimized by the Just-In-Time (JIT) compiler dynamically according to the platform you are executing on. I could go on and on.
Maven: Here's where you may want to have a chat with James. Before joining Cynthesis he worked for Microsoft in the Entertainment and Devices division group developing components for the Windows Mobile operating system that runs on tens of millions of so-called "smart phones". His work on that team was all native code.
Motley: Sucks to be him. I am willing to bet he is the victim of code complexity, a legacy code base, extremely long build times, nasty dangling pointer problems, and a host of other issues that are an order of magnitude more complicated than developing for .NET.
Maven: Yes, he told me that there were some nasty problems. But the point is that there are real reasons why the group chose to develop on a native C++ platform.
Motley: I'm waiting.
Maven: When you think about it, developing for mobile and embedded devices is almost like taking a step back in time a few years. Consider the type of hardware you are developing for:
- Devices are constrained by CPU - a 200Mhz or 600Mhz processor (if you are lucky) is the norm. Writing software that exhibits high performance is a critical concern.
- Devices are constrained by memory - 128MB of RAM (if you are lucky). Applications with high memory usage are not acceptable.
- Devices are constrained by unconnected power - rechargeable batteries last a few days (if you are lucky). Software that sucks CPU and other resources has a big impact on battery life. Efficiency is king.
- Devices are constrained by typically not having a floating point unit or graphics processor. As a result, the algorithms you choose must take efficiency into account.
When you consider all these constraints, you want to develop applications to be as lean and mean as possible. The Common Language Runtime (CLR) has significant overhead in the system and is a negative drain on efficiency.
Motley: Those concerns are less prominent in most other types of development, however.
Maven: You might think, but ignoring these constraints even on desktop workstations leads to much more bloated software and applications that do not play nice with one another. Although not necessarily high profile, the skills that a mobile developer possesses make her a better developer overall, regardless of application domain, platform or language. You started out on C++, didn't you?
Motley: Yeah, and I never want to go back. As far as I'm concerned, native C++ code development is obsolete.
Maven: C++ is far from obsolete. In fact, standardization of the new version of the language, C++ 0x, should be completed by end of 2009.
Motley: Great. I'll just take a job where developers use managed code and be happy.
Maven: That's fine, although there are many more reasons to join a team than just technology and programming language. We discussed that previously. Anyway, I would argue that you are a better developer now because you had a C++ background. You understand what a pointer is don't you?
Motley: Don't insult me.
Maven: Do you ignore the concept of a pointer in managed code?
Motley: Absolutely not. There are times to pass objects by reference. There are times when using COM Interop that I have to worry about AddRef and Release. There are times when I do server-side development that I have to explore heap fragmentation issues (and in rare circumstances heap corruptions). Understanding a pointer is a necessity.
Maven: I agree! In addition, and when writing an operating system like Windows Mobile, you may need finer control at many different levels of the architecture. You cannot take the hit in performance for garbage collection. You may need your own memory manager given hardware constraints. You need finer control over the creation and destruction of objects to ensure resources are freed as soon as possible.
Motley: Understood. It's just not for me. I did my time.
Maven: I prefer the .NET platform as well. James, however, just found such a fantastic team at Microsoft that he gave up his technology preference to build a cool application with super strong developers. Although COM and C++ have been around for years, they are here to stay for a while yet. There is lot of legacy code written in C++ that still must be maintained. Although we may wish that the entire development population wrote managed code, that day is still far off in the future.
______________________________
Maven's Pointer: Is Maven's "pointer" a bit of a misnomer if we talk mostly about managed code? Well, yes and no, as Motley indicated. Taking some time to understand the underlying technology behind managed code will improve you as a developer. This may include starting at the level of C++ but also delving down into intermediate language (what C# compiles into) and assembly language. By the way, if you understand how a Reverse Polish Notation (RPN) calculator works and its stack-based number manipulation, you already understand much of what you need to grasp intermediate language (IL).
Maven's Double Pointer Indirection: Microsoft made a big bet on .NET with Windows Vista a few years ago exposing the majority of the APIs as managed code. The best didn't really pan out and contributed to forcing a development reset partway through the cycle. Managed code has a great future for many different types of applications, but for developing operating systems, more improvements are in order.
Maven's Triple Pointer Indirection: This is a bit of a controversial topic. I'd love to hear the opinions of others out there. How long will native languages like C++ be around?
Maven's Resources:
Summary
Motley: I am a developer. I am paid to develop, not write e-mail all day. E-mail is sucking the life out of me and I can't keep up.
Maven: Use your Inbox as your to-do list, keep your Inbox to < 10 messages, categorize and/or create folders, use server-side rules to redirect e-mail, do quick triage of e-mail, use search, shut down your mail client.
______________________________
[Context: Motley is expressing his frustration over not getting any "real" work done lately. Maven, of course, is curious as to why that is]
<a loud bang from Motley's office area>
Maven: Whoa! What the heck was that?!?
Motley: You had better take a step back if you want to avoid my fists of fury. I am not having the greatest day.
Maven: What's up? Anything I can do?
Motley: Every time I blink there is a new e-mail in my Inbox. I can't keep up. I am now about 200 messages behind. I can't get any work done because I keep getting e-mail. I am sorry that my monitor has to take the brunt of my frustration, but you weren't around. How do you deal with the barrage of e-mail Mr. Smarty Pants?
Maven: E-mail is a tough problem. It can absolutely consume your entire life if you are not careful. There are a few tricks though that can make your life much simpler.
Motley: Like deleting them all with one fell swoop?
Maven: Not quite. Firstly, get off all distribution groups that do not add you value. As a senior guy, I know you want to be in touch with everything, but sometimes you have to let go. Ask yourself how many of those messages are actually relevant to your activities. Anything that doesn't qualify, unsubscribe. Missing an e-mail conversation will not inhibit your career.
Motley: I'm already trimmed as far as I can go, but I still get a ton of messages.
Maven: Next, use Outlook (or whatever e-mail client you use) to set up some folders for categorizing mail. I typically use a few folders for general discussion e-mails that do not contain any high priority items (e.g. the Mobile Devices daily news, CNET news, etc.), and a few folders for more specific work-related functions. I then set up some server-side rules to automatically move incoming messages that fall within those categories directly to those folders.
Motley: Yeah, but if I set up too many folders it won't solve my problem - I'll just get confused as to where things are that matter.
Maven: You don't want to have too many folders, but you want enough to get a significant chunk of lower priority messages out of your Inbox. Your Inbox then only contains messages that require prompt attention. You may treat your Inbox as your to-do list. If it contains thousands of e-mails, you'll find yourself lost. Try to get to a state where you have < 10 (or a screen full) mails in your Inbox, and stay there. When you do a mail check, either address it right away and delete it, categorize it, or move it to another folder. Moving to another folder and categorizing can be the same thing. Some people have three different folders for high priority (urgent and important), medium priority (urgent), and low priority (not urgent or important, but needs to get done eventually). Others, like me, use categories in Outlook and arrange the Inbox by category with high priority items at the top. The category names I use are:
- "3. Important" (colored red)
- "2. Medium Priority" (colored yellow)
- "1. Low Priority" (colored green)
You can use the number at the beginning to sort the Inbox with the important items first. I sometimes use reminders as well to ensure I get to an item by a certain time.
Motley: Less than 10 e-mails. Are you crazy?!? I have about 900 messages in my Inbox, of which 200 are unread!
Maven: Spend a bit of time cleaning that up. Get down to < 10. Make it a daily goal to keep the number low. Start each day with an initial triage - look at the subjects and delete anything that is not of concern. Consider whether a rule is necessary to get that kind of mail out of your Inbox. I also like to color-code messages with me on the To: line. Those messages are generally more important than messages sent to a distribution list that I belong to.
Motley: What about all the stuff you put in folders? You have to get those at some point! It's also a lot more places to look for a specific message.
Maven: Yes, perhaps once a day. You don't want distraction throughout the day on messages that are less important. Set aside time once per day to scrub non-Inbox messages and perform bulk deletes as necessary. If you find one that requires your attention, move it to your Inbox and consider modifying the rule for the future. For finding messages, name your folders intuitively. Also, most e-mail clients these days have quick search functionality built-in. Leverage it.
Motley: Even with all these rules in place, I'm still going to get 25-50 messages per day in my Inbox. That's still a lot of distraction wise guy. And if patterns hold, half will be from you!
Maven: You exaggerate. I am sure I don't send that much mail. Firstly, though, you need to turn off that annoying pop-up new mail indicator that most e-mail clients (like Outlook have). It is distracting. Next, shut down your mail client. Open it once in the morning, once around lunch, and once at the end of the day at most. Set the expectation with your co-workers that you will not respond instantaneously to e-mail. I bet that one action cuts down on your e-mail. Of course, then you have to take care of in-person distraction. Shut your door (if you have one) when you need concentration time, find another place to work with your laptop or throw on some headphones.
Motley: Apparently they say in Alcoholics Anonymous that the first step to solving a problem is admitting you have one. I admit it - I can't turn off that mail indicator. If I do I'll just be wondering whether someone just sent me new mail.
Maven: At least you admit you are an addict! Trust me, though, once you see your productivity rise because you limit e-mail checks to three per day, you will thank me. I wonder how you will feel when I suggest that when you go on vacation to set an out-of-office message indicating that you will be deleting all e-mail while you are away unless it has "SAVE:" in the subject line?
Motley: Get lost. I could never set a rule to auto-delete mail like that.
Maven: I have found that's the only way to a stress-free vacation. It worked for a 3 month vacation that my previous manager took. Just try out the above tips and see how they work for you. Cutting down on e-mail is a huge key to developer productivity, especially in a large company. I've heard that Microsoft culture revolves around e-mail.
Motley: Sucks to be them. Although I guess we are in the same boat to some extent, just not to that same magnitude. Ugh. I'll try anything.
______________________________
Maven's Pointer: It is a great feeling having an empty Inbox. It's a great to-do list, and there is certain satisfaction in addressing all the items on your to-do list. There are many strategies out there for handling mail and no one strategy works for everyone. I do believe that keeping your Inbox clean, however, is the best way to go. Regardless of how you do that, it is a valuable and effective technique in organizing your daily life. One last tip: if an item stays in your Inbox for more than a few days, it's probably not important and something you are not motivated to deal with. Delegate it (if necessary) and delete it.
Maven's Resources:
Unfortunately, work, a small vacation, and personal stuff (but mostly work) got the better of me this week and I did not have a chance to write a new adventure with Maven and Motley. They'll be back next week in full force if that work thing doesn't keep getting in the way. Did I mention work is taking up quite a bit of time these days? Ah, yes, that work thing.
In the meantime, here are a couple of quick recent random findings of mine:
-
To play practically any song given the artist and title, visit this very simple web site:
http://songerize.com.
-
I recommend you keep an offsite backup of your personal files. The one I use is:
http://www.mozy.com.
-
James.
Maven: Motley, I just wanted to wish you a Happy Anniversary!
Motley: In case you haven't noticed, I am not married. Did you get into the glue again?
Maven: No, glue is Marshall's thing, not mine. In any event, the middle of March marks our first anniversary together at Cynthesis! I thought I would celebrate by giving you this photo of Marshall beating me over the head on your prompting.
Motley: Ah, yes, happy times. It shall be posted prominently on my office wall.
Maven: In honor of our one year anniversary, I am taking a small trip to California and Arizona for a week. I am going to miss our daily interactions.
Motley: You mean I get peace and quiet for a whole week?!? I finally have some time to get some real work done. Are you sure you don't want to go for two weeks? Three weeks? A month?
Maven: I know you'll miss me despite all your banter. Have a great week.
______________________________
Maven and Motley will back on April 1, 2008. In the meantime, please pass along any suggestions for topics and pointers to other valuable resources you may have come across.
Summary
Motley: Affinity exercises? How do I work that sideways "8" into design brainstorming?
Maven: Use affinity exercises for generating lots of ideas and prioritizing them. Define the topic, generate ideas, categorize, discuss, prioritize using dot voting, add up the votes, and create the summary.
______________________________
[Context: After the talk on team checklists, Motley was motivated to create a team code review checklist, but had some difficulty]
Motley: After our recent discussion on checklists, I was inspired to create a team checklist for use in code reviews. A few common problems appear fairly regularly, and I want to ensure everyone looks for them during a code review.
Maven: Sweet! Glad to see you are implementing some quality practices. Checklists provide a great reminder of frequent errors, as we discussed.
Motley: I thought I would get everyone together to determine what issues to look for in code as a team. We ended up focusing on one or two things and had in-depth discussions. By the end of the hour-long meeting, we didn't have much that was useful. I then had a chat with Mort and we came up with too many ideas - the opposite problem. We didn't know how to narrow them down. In the end we had nothing. Pretty much a waste of my time and the team's time.
Maven: Ah, yes - the unstructured brainstorm session. Brainstorming with a team is actually a very difficult exercise if you don't set some ground rules and put some structure in place. Have you ever tried an affinity exercise?
Motley: Affinity exercises? How do I work that sideways "8" into brainstorming?
Maven: Affinity. Not "Infinity".