Brian On Software

Recently, a user group held a conference whose subject was Domain-Driven Design with nHibernate. Now, this is a really cool topic of discussion! So, I decided to attend the conference in order to improve my perspective and knowledge on the subject. Little did I know that the speaker was an introverted programmer who greatly lacked in public speaking skills. Many people, including myself, left early, as the presentation became unbearably tedious and awkward.

What follows is a list of tips which I feel to be important when it comes to giving a presentation. This is not an exhaustive list, so I hope you would add your own comments to elaborate on these ideas or to add to the list. [I am also looking to improve my communication and presentation skills, so these rules and principles also apply to me].

Tip #1: Introduce yourself properly

When I was a kid and people asked me what my name was, I used to reply “My name is Brian…don’t you know that?” You see, back then, I thought everybody knew my name: it’s a common name, it’s easy to remember and it’s simple to pronounce. However, in reality, this is not usually the case. Therefore, before beginning a presentation, introduce yourself to your audience. What is your name? What do you do for a living? Why do you want to talk to us about your subject? How can we contact you? Do you have a Web site or a blog?

Tip #2: Make eye contact

Bear in mind that the audience came to see YOU. Therefore, you should be mindful of the fact that we have decided to take time out of OUR day to see YOU, when we could be somewhere else (at home, a friend’s party, a late night dinner, etc.) That being said, PLEASE acknowledge this fact by at least looking at your audience. Don’t stare at the ceiling, the floor or the walls. Don’t stare at your PowerPoint slides either. I think it costs about two calories to move your eyes from one direction to another at variable intervals. In other words: it doesn’t hurt and it doesn’t take a lot of energy to do that. I know some developers are very introverted, and that is in their nature, but would you ask someone out on a date while staring at the wall or the ceiling instead of looking into his/her eyes? This takes practice, but the resulting impact on your audience is well worth the effort!

Tip #3: Talk with a smile

Do you know that the human being is the only living being in Earth that can smile to express different emotions? There are hundreds of muscles and nerves that are being contracted when you smile. Yet it doesn’t hurt. In fact, smiling at an audience changes the atmosphere and the ambience of the room to make it more natural, more humanized and more comfortable. Again, would you ask someone on a date without smiling? I don’t think so.

Tip #4: Move around a little

Just like a shark cannot stay alive without swimming around, so should you be moving and walking around a little on the platform. That platform is yours and you should feel free to walk on it so the whole audience can have a chance to feel your presence and to see you. Don’t stay near the computer just because you want to be there for clicking that button to go to the next slide. The computer is just a tool, not an altar.

Tip #5: Carefully prepare your presentation

Take the necessary time and resources to prepare your material: watch out for grammatical errors which can compromise your credibility, don’t go overboard with the information for a slide. Just like a good class design, your slide should be highly cohesive. What is your intent for a given timeframe? That answer should be reflected on your slide. I personally don’t care much for PowerPoint slides as a participant. What you’re telling me should be enough to understand your intent. I’ll look at your slide to complement your vision or your intent, not to get a second understanding of what you just said. Another thing you can do is to make your PowerPoint presentation available to everyone or by request. That way, the audience can focus on you in a more relaxing manner because they know that your presentation is there for them to look at anytime.

Tip #6: Anticipate obvious questions that could arise and prepare your answers

If your audience is at all interested in your subject, be sure that some people will ask you questions about it. For this, I like to imagine myself as part of the audience and see another projection of myself giving a talk. What kind of question could I ask the speaker right about now? Maybe something I said wasn’t clear or needed an example to better complete the picture. For some abstract or complex subjects, you can try answering some questions related to the 5Ws (Who? What? Where? When? Why? How?). You can also ask a friend what he thinks about your material. Prior feedback is always a good thing!

Tip #7: It’s okay to admit that you don’t know it all (However, do not use this as an excuse to come unprepared!)

This one is simple, but very hard to act on. If you are asked a question which you are unable to answer, just say these three little words: I don’t know. It doesn’t mean that you are completely ignorant. It just means that you don’t know. Even the greatest world leaders don’t have all the answers…no one does! Don’t sacrifice your credibility and your professionalism by risking an incorrect answer or solution. I remember someone once told me “Brian, it is better to remain silent and thought a fool, than to open your mouth and remove all doubt.”

Tip #8: Have a plan B in case something goes wrong

Over the years, I have come to realize that Murphy’s Law is true and no one is safe from it. Not even developers. The law states that whatever can go wrong will go wrong. Therefore, prepare a second plan (or more!) in case things don’t go as planned. For example, if you’re modifying code in front of your audience and your system crashes, you shouldn’t take time out of your presentation to fix the problem. You will lose your audience!!! Just scrap the code and use the duplicate that you have as a backup.

There are many (free) resources online about how to improve presentation skills. I strongly suggest you to visit Kathy Sierra’s blog on human usability. It’s really worth it!

This review is for Leadership and Self-Deception, from the good folks at The Arbinger Institute. It was actually my pastor who lend me this book following a talk I had with him about leadership in life and business; and if you know something about church ministries, you’d know that if it’s good enough for a pastor (i.e. a leader), then it’s certainly good enough for you. So anyways, I took the book home, and one week later, my life has improved in both a personal and professional level. This book is about 170 pages long, and it is very easy to read, in other words, you won’t need a dictionary to lookup every fifth word.

In short, the story is written as a narration of a young and new manager at a world-renowned and respected corporation. This company, Zagrum, is the best in its market, because its results are driven by people who are themselves driven by other people, instead of being driven by their own ego. The concept of self-deception is portrayed as "being in the box". You get "in the box", when you betray yourself. In other words, self-betrayal gives you a free ride to self-deception. What this means is that once you’re in the box, you have trouble seeing the real problem (such as lack of communication, trust, respect, commitment, etc.) at hand, and even more trouble in finding a solution to fix it, because you are blind to see that the problem is not the other people, but yourself. How do you know this? The answer is simple: you see other people as objects, instead of people. And as you probably know, it’s hard to understand, speak to, listen to and learn from objects. People have needs, cares, fears and hopes. How to manage and influence people is at the core of leadership, and at the end of it all, your heart is the foundation of leadership.

Just to give you a glimpse of the material you’ll learn through this book, I’m including an excerpt that I found very helpful.

Here, Bud, an executive manager at the company teaches Tom, the new manager, that there is a difference between knowing the material and living the material (the material being knowing the truth between being in the box and out of the box):

Knowing the material

• Self-betrayal leads to self-deception and "the box."
• When you’re in the box, you can’t focus on results.
• Your influence and success will depend on being out of the box.
• You get out of the box as you cease resisting other people.

Living the material

• Don’t try to be perfect. Do try to be better.
• Don’t use the vocabulary – "the box" and so on – with people who don’t already know it. Do use the principles in your life.
• Don’t look for others’ boxes. Do look for your own.
• Don’t accuse others of being in the box. Do try to stay out of the box yourself.
• Don’t give up on yourself when you discover you’ve been in the box. Do keep trying.
• Don’t deny you’ve been in the box when you have been. Do apologize, then just keep marching forward, trying to be more helpful to others in the future.
• Don’t focus on what others are doing wrong. Do focus on what you can do right to help.
• Don’t worry whether others are helping you. Do worry whether you are helping others.

And finally, I had to include a powerful, yet so true message that I believe people in organizations (doesn’t matter their position, rank or title) should understand and remember daily:

"Tom," he said, putting his hands on my shoulders. "The thing that divides fathers from sons, husbands from wives, neighbour from neighbours – the same thing divides coworkers from coworkers as well. Companies fail for the same reason families do. And why should we be surprised to discover that it’s so? For those coworkers I’m resisting are themselves fathers, mothers, sons, daughters, brothers, sisters. A family, a company – both are organizations of people. That’s what we know and live by at Zagrum" (Page 168).

I am not a pro at writing book reviews, so the approach I’m taking is the same one I would expect someone to convince me to read a book. And since I’m a simple person, I am expecting simple results. So I hope this book review was simple enough to convince you to get this book from a public library, a book store or a friend’s desk. Trust me, you won’t regret it!

An athlete doesn’t instantly compete in the Olympics simply because she pumped her Reebok sneakers. A musician doesn’t instantly play Mozart symphonies just by listening to one of his masterpieces . A general doesn’t win a war simply by watching a war movie. All these examples have an intrinsic way of dealing with self-realization and application:

• It takes time
• It takes practice
• It takes motivation
• It takes inspiration
• It takes discipline
• It takes courage
• It takes effort
• It takes concentration
• It takes perseverance
• It takes education

It takes the same energy as the examples above to become a key, valuable and respected software professional, e.g. programmer, developer, architect, tester, SQA, vendor, trainer, etc. So how do you become a key leader in the field? Are there any steps to follow? I don’t think so. However, I do believe there are tips one can consider.

Here are my ten simple tips on how to become a valuable software professional.

1. Read literature on the subject

When was the last time you read a book or an article on a specific subject related to software engineering? If you’re not in the habit of taking a piece of literature in your hands, I hope you will break that habit, because reading is a privilege that not most of us have, and it can help you grow both as a person and a professional. In Code Complete, Steve McConnell writes that the average programmer reads less than one technical book per year. Reading a book written by a pioneer like Caper Jones, Cem Kaner, Karl Wiegers or Gerry Weinberg will set you apart from the majority of beginners and some professionals, because you are learning from experts in the field and their mistakes from the past can be very valuable for your future. That doesn’t mean you won’t make mistakes! Everybody makes mistakes. This is how you become the best in the field: by trying and by failing. The question you should ask yourself is Why would I waste my time in repeating the same classical mistakes instead of preventing them? The authors I have mentioned above are pioneers in the software development field, and they have taken time to write down their mistakes and their solutions for them. There are various medium of literature to read from: magazines, books, ebooks, blogs, newsletters, whitepapers, tutorials, etc. A tip: start out general so that you can build your habit of reading, and as time goes by, you can specialize in various areas such as programming, architecture, patterns, requirements gathering and analysis, software quality, testing, etc.

2. Write literature on the subject

Share your knowledge with others by writing articles, tutorials, books, or other type of literature in magazines, blogs, etc. Sure it takes time, but the benefit of it is much greater. I took almost five hours of effort to write this article, but if it can help at least one student, one professional or one aficionado, then it is worth it. There is also some research involved in writing a technical article, so you’re still returning to the first tip: reading; therefore, you’re still learning and growing. It’s a win-win situation.

3. Attend conferences

Some are free and some are not, but depending on the scope of the conference, you will learn a thing or two. Maybe you won’t learn anything technical, but you sure will learn something about communicating to an audience. Try to make it a goal in your professional life to attend at least one or two conferences a year. Remember that speakers have a mix of experience and research when they present a topic. They took the time you didn’t have to present you something worthwhile. You can attend international, as well as local conferences. For example, in Montreal there are bi-weekly conferences on Microsoft technologies (Microsoft Visual Studio Group of Montreal), Agile practices (Agile Montreal), software process improvement (SPIN Montreal) and software quality and testing (SQPA). In any case, conferences give you the opportunity to also meet new faces and network with other professionals like you. This tip is also related to reading and writing, since you can read about the topic before attending a presentation, and then write about it to solidify your understanding and sharing your opinion with the community.

4. Attend a professional or academic class, training or seminar

I am pro education and I think every human being should be glad to have the ability to learn. If you’re a student, I say to you “Well done. Don’t give up.” If you’re a professional, I say to you “Well done. Don’t give up learning.” There is something special and worthwhile when a little group of people are sitting in a class, and learn altogether from a teacher. I agree, sometimes the teacher isn’t the best, but remember that the teacher once sat in the same seat as you did. If you don’t learn from the teacher, you will learn from the textbooks, the materials, or even better: the other students; therefore it’s still a win-win situation. I don’t care much whether it is a professional class or an academic class. I know one is more pragmatic and the other more theoretical, but you’re still going to learn something. If something is too theoretical for your taste, see if you can do some research on the subject or attend a conference on it to get a better understanding.

5. Listen to audio on the subject

There are many podcasts available on the Internet about software development, processes, practices, tools, etc. Just google for “software development podcasts”, and you’ll see for yourself. Listening, as you know, is not the same activity as reading or writing. Your brain works differently. Nevertheless, the outcome is the same: you will learn something. Now the trick is to find the time to listen to one. I suggest listening when you’re doing some physical activity, such as cleaning the house or exercising at the gym. Don’t listen when you need to concentrate mentally on something, since it’ll be harder to capture the full intent of the show. It’s like drawing a square with one hand and a circle with the other hand: it’s possible, but very hard to do.

6. Watch a video on the subject

You can also watch online videos, presentations (aka webcasts). Some presenters also use PowerPoint presentations so that you can take notes while listening. There are various topics being presented by independent individuals or corporate speakers. If there’s something you didn’t quite get, you can always rewind the video. Some presentations also allow online real-time collaboration, so that you can ask questions to other people tuned in. I sometimes take some time to watch dnrTV, which uses a Camtasia capture of the presenter’s computer to better visualize his intent.

7. Join a professional society

Joining a professional society will expand your domain knowledge with other professionals who might have more experience than you. For students, this is incredible because the fees are just a fraction of the regular price. For instance, I pay less than 30$ a year for my ACM and IEEE membership. In return, I get valuable newsletters, magazines and invitations to participate in my local chapter. For professionals, this is an excellent way to build your network. If you’re working at a company, verify if the company can pay your membership.

8. Apply your knowledge

When I first started to learn how to drive, I spend my time reading books on how to drive, how to park…basically a Driving For Dummies kind of book. But the very first day I sat behind the wheel and accelerated, it was as if I have forgotten everything about driving. You see, sometimes theory without application is null. When you read an article, listen to an audio cast or watch a presentation, take some time to apply what you have learned. You can write about it as I have mentioned above, or even teach. You’ll be amazed in discovering new things about the related subject as you do so. You can also start a new project, or even participate in the development of one (e.g., SourceForge).

9. Get certified

What a greater way to apply your knowledge than to pass a formal exam on a subject? Most respected certifications have a body of knowledge as its core basis for knowledge and understanding. Personally, I prefer going with independent certifications such as the ones from IEEE, QAI or ASQ, instead of company-specific ones like Microsoft or Oracle, because I prefer to focus on the seldom changing software principles rather than the always changing technologies or tools, but that is my own opinion. Getting certified doesn’t give you the title of Master of a subject, but it does show your competency on it. For more information on various software certifications, I strongly suggest you to visit this site www.softwarecertifications.org. By the way, the software engineering field also has its own body of knowledge in case you were wondering: the SWEBOK.

10. Have fun investing in yourself

Last but not least, have fun when learning or applying your knowledge. If you’re tired of reading or listening to something, just set it aside and do something else. I truly believe that God gave us enough hours in a day to become the most we can be in a lifetime. Remember to live and enjoy your life. Technology will come and go, even after you die. That being said, ask yourself if there’s a contribution that you can bring into this field that can help others in the future. I’m glad for people like Steve McConnell, W. Edwards Deming, Joseph M. Juran, Timothy Lister, Tom DeMarco, Cem Kaner, Eric Evans and the like who have helped me grow to become a good software professional thanks to their writings and presentations.

The software development or engineering field is truly amazing. I hope this list of tips will help your knowledge on this subject to grow.

The term ‘software engineering’ was coined some forty years ago at the 1968 NATO Software Engineering Conference, in Germany. Software engineering is a new branch in the engineering field when compared to other engineering disciplines such as electrical, mechanical, building and construction engineering. No wonder that most of the world sees the profession of software engineering as an immature and young discipline. Nonetheless, the field of software engineering is very promising. In the last forty years, there has been a large amount of breakthrough, innovation, change, improvement and research in the fields of computer science, mathematics, business, management, leadership, human behaviors, and interactions, which are all pillars that feed and support the engineering practice that we call ‘software engineering’ today. As you may or may not know, a liberal profession is more often based on failures rather than success, and as you should know, there have been many failures in the area of software engineering and development. However, most of these failures have been documented in order to avoid repeating them, but most importantly their solutions have also been documented. As I said earlier, the discipline of software engineering encompasses areas related to computer science, mathematics, business, management, leadership, etc. That being said, there are currently many roles that a person can play in a typical software project today. In fact, if you search for ‘software’ as a search criteria for an employment opportunity in Monster or Workopolis, you will see what I mean. Most popular roles in a typical software projects include software project manager, business analyst, software architect, specialist in software quality assurance, software tester and software engineer (or software designer, software developer). A good question to ask ourselves (especially if you’re involved in HR or recruitment) is “How do I know what this specific role will do and won’t do in this project?”. Another question can be “What should I expect this person to know in order for him or her to perform well at this position?”. Fortunately, some smart people have taken time to answer these kinds of questions. In fact, many of the answers can be found in what we call today a Body of Knowledge (BoK). A BoK is "…an aggregate of what is known and understood within a defined field of endeavor due to familiarity gained through experience or association." Did you know there is currently a BoK for each of the roles that were mentioned above? Yep. Today you have a BoK specific to project managers (and even software project managers), business analysts, software architects and other roles. Some of them are in their final publications and others are in draft, but regardless of their state, these BoK are constantly being improved and approved by a committee. Some of them are freely available and others can be purchased. Nevertheless, you can use them today in your own organization to clarify the expected knowledge and activities that a role must support in a project. If you already have a framework available in your organization that guides people in their specific roles, you could use these BoK to improve on what you already have. Furthermore, if you’re interested, you can also participate in developing and improving a BoK that fits with your wisdom and expertise on a specific area. Another thing you might want to know is that there are also worldwide certifications which are solemnly based on these BoK, and which can help you to not only show your expertise in an area, but also to participate in making your profession more professional. I know this is a large post, but I truly believe that taking time to download (or buy) some of the guides related to these Body of Knowledge documents and to read them (alone or in a group) can be very beneficial because not only will you be learning more about your profession, but you will also learn to embrace it and make it better. My tip when reading these kind of documents is to see what makes sense to you and your organization, what you can use, what you could improve and what you can discard to make your projects more successful and your projects’ team members more knowledgeable in their activities. I’ll finish this post with a list of common BoK which might be of great interest if you’re in the software engineering field.

• For project managers, there is the popular Project Management Body of Knowledge (PMBOK) which is regulated by the Project Management Institute. The Guide to the PMBOK is the recommended source of information to pass the Project Management Professional certification.

• For software project managers, there is the Software Project Manager Body of Knowledge (SPMBOK) which is regulated by the Quality Assurance Institute. The Guide to the SPMBOK is the recommended source of information to pass the Certified Software Project Manager certification.

• For business analysts, there is the Business Analysis Body of Knowledge (BABOK) which is regulated by the International Institute of Business Analysis. The BABOK is the recommended source of information to pass the Certified Business Analysis Professional certification.

• For software architects, there isn’t yet an official body of knowledge (as far as I know). Nevertheless, I highly recommend visiting any of these sites which are fully committed in making the profession of software architects more mature: the Worldwide Institute of Software Architects and the International Association of Software Architects.

• For software engineers, there is the Software Engineering Body of Knowledge (SWEBOK) which is regulated by the. The Guide to the SWEBOK is the recommended source of information to pass the Certified Software Development Professional certification and is available in PDF, HTML and hard cover book. I strongly suggest you to listen to the DotNetRocks show with professional software engineer Steve McConnell to have a better view on this type of certification.

• For software quality assurance specialists, there is the Software Quality Assurance Body of Knowledge (SQABOK) which is regulated by the Quality Assurance Institute and the Software Quality Engineering Body of Knowledge (SQEBOK) which is regulated by the American Society for Quality. The Guide to the SQABOK is the recommended source of information to pass the Certified Software Quality Assurance certification. The Guide to the SQEBOK is the recommended source of information to pass the Certified Software Quality Engineering certification.

• For software testers, there is the Software Testing Engineering Body of Knowledge (STEBOK) which is regulated by the Quality Assurance Institute. The Guide of the STEBOK is the recommended source of information to pass the Certified Software Test Engineer certification.

These are the most common, popular and important body of knowledge documents for each of the areas that support a typical software engineering project. Of course there are many more which haven’t been written yet, i.e., the software architecture body of knowledge, but with time and dedication, people like you and me will make this “new branch of engineering” a more solid and respectful one. Feel free to add your comments and provide links to other useful resources related to body of knowledge documents that I may have missed.

Resources:

• "Software Engineering: An Emerging Profession?", an excellent article written by David Alex Lamb which presents the current state of software engineering and where it is heading.

• Software Engineering Professional Certification Programs by Learning Tree International provides a list of other software engineering-related certifications that might be interesting for you.

I’m in the process of ending my third and last internship for the bachelor’s degree. For the last few months, I had the privilege of working for a software quality engineering firm (software quality assurance, software quality control, software process improvement, training, etc.). I never thought I would enjoy learning so much from that field and have a keen passion for it all. Before starting my internship, I always thought that software testing was for developers who couldn’t keep up with the pace of development, or weren’t as technical as they should’ve been, therefore they had no choice to accept that position to pay their bills.

Man was I wrong. Very wrong. I realized that there is much more elements involved in testing, than just pressing a record/play button. In fact, there is a lot of human and technical abilities that must be taken into consideration when dealing with software testing. On the human side, there is

• Communication (been able to talk to other testers, developers, managers and clients)
• Leadership (have the ability or responsibility to drive your team members or colleagues to reach their goals)
• Confidence (in yourself, your education and your abilities as a tester)
• Courage (to step up and say the real facts of the situation, especially before delivery)
• Wisdom (learn from your mistakes and also from other people’s mistakes)
• Intelligence (software is complex enough to know this)
• Respect (for yourself and others in the team)
• Humility (it’s okay to say you were wrong. Show this, so that other team members can be this way too.)

On the technical side there is

• Software development lifecycle
• Project management
• Best practices and methodologies (Agile, UP, TDD, etc.)
• Standards and recommended guidelines
• Software development key areas (business processes analysis, requirements gathering and management, design and development, testing, configuration and management, build and deployment strategies, etc.)

I could go on and on, but I’d stop here, because this wasn’t my intent for this post.

Oh yeah, and for the first point, quality is a major activity in architecture and development, so there’s still work to do in that area.

Ok, my intent in this post was to invite you to read an interesting article that I’ve read this morning entitled "Software Testing and Industry Needs", published by the IEEE in August 2006. It basically talks about the state of the practice of software testing in the industry, from the viewpoints of five experts in the field :

• Robert L. Glass
• Ross Collard
• Antonia Bertolino
• James Bach
• Cem Kaner

If you are a Computer Science or Software Engineering student, or even a current practitioner, and you’re curious about the field of software testing, or maybe even thought about changing careers, I strongly suggest you to read this very interesting article. I’m including some of my favorite quotes in this article, to give you a more general idea of the each respondent’s viewpoint.

Robert L. Glass states that

I actually do believe that most software testing in industry effectively meets industry needs. I base my bias on the observation that this is the computing era – an era that wouldn’t be successful without successful software – and on my belief that software can’t be successful without effective testing.

Ross Collard says that

Effective testing is a quest and, like any quest, includes intellectual challenge, passionate debate, and the excitement of discovery. Rewards for the best 20 percent of testers typically include exponential career growth, substantial monetary compensation, and wide influence. There is plenty of room for more good testers.

Antonia Bertolino thinks that

…Testing impacts the whole life cycle, because any testing technique presupposes adequate preparation, modeling, and documentation.

James Bach believes that

Industry ultimately takes care of its own practices. Each company does what it believe will work. What we need to resist – and resist strongly – are efforts to take away each company’s right and responsibility to set practices for itself.

And finally, one of my favorites in the field, Cem Kaner tells us that

Most industrial projects have many stakeholders who have diverse interests and conflicting priorities. The purpose of testing during development is to help those stakeholders understand what they’re getting, in time to correct a weak programming practice or (re)negotiate the design.

A couple of months ago, I purchased a new MX Revolution mouse from the good folks at Logitech. I love it so much, that I decided to get another mouse from the Revolution series for work, this time a VX Revolution. Unfortunately, while playing with these computerized ‘mice’, I had trouble figuring how to open a link in a new tab under Firefox (2.x or newer) or Internet Explorer. I used to just hover on the link and click the middle button of the mouse and, like magic (well, not really), the link would open in a new tab of its own. Talk about productivity! I think I was saving myself three or four calories by clicking on the middle button instead of moving my index finger to hold the CTRL button on the keyboard and left-click on the link. But what about now?

After searching around on the Web, I couldn’t believe that no one wrote a solution for this ‘problem’. Is this an impossible task for this kind of mouse or aren’t people trying a little bit more? So I took some time to find a solution to this little problem…

Here’s what I did to enable the ‘open link in a new tab’ under Firefox and Internet Explorer (IE) by clicking the middle button of your MX or VX Revolution mouse from Logitech. You do have to install the SetPoint software that is provided with any good product sold by Logitech or download it directly from Logitech’s website, in order for this to work. I’m currently using SetPoint version 4.0.

Follow these simple steps to enable this functionality with your MX/VX Revolution mouse:

1. Launch the SetPoint program or right-click the icon on the taskbar and click on “Mouse and Keyboard Settings”
2. Make sure that your mouse model is set to “MX Revolution” or “VX Revolution” (Step 1).
3. Select the third item from the “Select Button” (Step 2) which corresponds to the middle button of the mouse.
4. Under the “Select Program” listbox (bottom left of the image), click on the “Manage Programs…” button. If you don’t see the Firefox or IE application in the list of programs, make sure you add the full path to the executable file, i.e., C:\Program Files\Mozilla Firefox\Firefox.exe. Close the window if Firefox and/or IE is already there, or if you have just added it.
5. Now click on the Firefox program or the Internet Explorer program in the “Select Program” listbox (you can personalize all your programs, but here we’re just concentrating on Firefox and IE) and under the “Select Task” (Step 3) list of buttons, click on Other (the last one), then click on the “Select Function” button.
6. In the “Select Task” window, make sure to open the listbox and select the “Middle Button” option (press ‘M’ on your keyboard if you can’t find it due to impatience in getting this thing done). Then click on OK to close this window, and OK again to close the main (parent) window.

Picture 1. Here’s the picture of what you should see in the mouse configuration settings of SetPoint

You should now be able to open a link in a new tab under Firefox or IE simply by clicking the link with the middle button of your MX or VX Revolution mouse.

I came about this excellent list of ten common myths or suppositions about the field of Software Engineering. The list is maintained by Sahil Thaker. According to him, these are the top ten myths about Software Engineering :

1. Software Engineering is the same as Software Development
2. Software Engineering has no formal basis – it is an art rather than a science
3. Software Engineering is a well-established field
4. Software Engineering involves more testing, requirements analysis, and documentation
5. Practicing UML, MDA, Aspect Oriented Programming, eXtreme Programming makes one a Software Engineer
6. A Software Engineer is he who handles both technical and managerial issues in software development
7. Software Engineers are much too different from Computer Scientists
8. SWEBOK represents the state-of-the-art in Software Engineering
9. Software Engineering is "engineering"
10. Software Engineering is not "engineering"

Would you agree?

As a professional software engineer, I’d have to agree with what he’s saying. Even some professional software organizations, right here in Montreal, have no clue about the difference between software engineering and software development. For example, this year at the University, there were some high tech companies on the campus to recruit co-op students or recent graduates, and most of them were looking for software engineers to code various algorithms in C or C++, design Web sites with the latest buzzword-oriented technology, etc. Hopefully they’ll take a couple of minutes to read the entire article.

Last March, Mike Cohn gave a tech talk at Google about Agile estimation, Scrum and the Planning Poker. In this 90 minutes presentation, Mike shares his insights and experience on software estimation using an Agile perspective and by providing many concrete examples to better understand the concepts. He also provides useful information about how an organization can improve its quality and estimation by embracing a couple of Scrum activities such as the Daily Scrum and the Planning Poker. Furthermore, he informs the audience that there is actually a website dedicated to provide a free and useful tool to help organizations engage with the Planning Poker. The tool is convenient for distributed teams as well and suited for organizations who lack a formal system to track and manage their estimation. I never heard of this tool prior to watching this tutorial. I’m sure some managers at work will find it pretty useful too. I hope.

The idea behind planning poker is simple. Individual stories are presented for estimation. After a period of discussion, each participant chooses from his own deck the numbered card that represents his estimate of how much work is involved in the story under discussion. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again. Planning poker is the best way we’ve found for agile teams to estimate. It’s primary downside has been that all participants had to be sitting in the same room with a physical deck of cards in their hands.

The whole tutorial is available on YouTube as two separate videos (Part 1 and Part 2).

The PowerPoint slides to the videos can be found here.

I highly recommend to any developer, lead, manager and executive to watch this very educating and entertaining video which I’m sure will help you to better estimate your next work activities and products. My suggestion is to watch it with some co-workers during lunch…with pizzas.

Since the past year, I’ve been practicing the art of writing unit tests to help me drive a design before writing any code to support it. It came to my surprise that this practice, whether known as Test-Driven Development(TDD) or Behavior-Driven Development(BDD), has been used and preached by many leaders of our field for quite some time. In fact, Martin Fowler, a thought leader in software development for the enterprise and in his excellent book about refactoring, "Refactoring: Improving the Design of Existing Code", which was published in 1999 (almost ten years already), mentions the practice of testing your design with unit tests before writing your business or logic code. The fourth chapter of that book, entitled "Building Tests", is dedicated to promote this activity in your software development process. And guess what? It doesn’t even mention the "test-driven" word! Is this an easy route to follow or even to diverge from our comfortable and traditional way of writing code before even fully understanding a requirement?

"Of course, it is not so easy to persuade others to follow this route. Writing the tests is a lot of extra code to write. Unless you have actually experienced the way it speeds programming, self-testing does not seem to make sense. This is not helped by the fact that many people have never learned to write tests or even to think about tests. […] In fact, one of the most useful times to write tests is before you start programming. When you need to add a feature, begin by writing the test. This isn’t as backward as it sounds. By writing the test you are asking yourself what needs to be done to add the function." – Martin Fowler, Chapter 4 "Building Tests". An excerpt of "Refactoring: Improving the Design of Existing Code".

In my opinion and experience, the reason why TDD works is because it helps us to build correctly something that we don’t fully comprehend. This is especially true if the project domain is new to us, if we don’t have all the requirements set before us, if our experience in designing and thinking about software isn’t as broad as other experts, etc. Of course, we might have a general, high-level idea of what the application must do or should do, yet we don’t fully grasp the mechanics behind it. By mechanics, I also throw in the vision the software is trying to realize. Knowing what it must do or should do is a good starting point for laying a foundation on which the rest of the application can be built. Writing or thinking about unit testing helps to understand what the foundation should look like, and feel like, from the user’s point of view of our code. I tend to think it as paint artist drawing a painting. Most of the time, he doesn’t know immediately how to draw something very specific (a shape, a concept, an angle, a shade, etc.) and which exact color will be used to paint it. But, he sure knows what he wants to draw or what needs to be painted. It’s the same thing in music, in martial arts, in cooking and yes, even in software development. It’s the constant battle that goes on in front of a whiteboard, a sheet of paper or a CASE tool when designing and coding. Have you guessed it? The answer is pretty simple. It’s the battle between the what and the how. "What should this functionality accomplish versus how it should be implemented?" "What should this method expect versus how it should handle the expectation?" As a side note, I once heard that Linus Torvalds, the author of the Linux kernel, is an exemption to this reality. Apparently, he sees the code that needs to be written in his head and writes it; and if you tried to reverse engineer his code, it’ll produce a very solid design. Because there aren’t many Linus Torvalds within our organizations, we can look to useful, simple and pragmatic practices. Writing unit tests upfront helps me to drive a design that’s not entirely understood, but at a minimum, partially understood. It also helps me to bring forth changes to my design. In software development, these kinds of changes are known as refactoring. I highly recommend Martin Fowler’s book on refactoring to learn more about the patterns for effective refactoring. So what did the test-first approach to software development taught me so far?

• It taught me that refactoring my work can be done in a much easier and safer way
• It taught me that I would understand the design, therefore the application, much better if I see it through the eyes of someone who will use my code
• It taught me that there is an ongoing battle in my head about knowing WHAT my class should do and HOW the code should do it. This sort of "mental war" is a good one to have, since it forces me to carefully think about various OO principles (encapsulation, relationships, inheritance, etc.) when designing and coding
• It taught me that the old, traditional way of developing software (Big Design And Requirements Upfront) doesn’t work for every projects nowadays
• The concept of testing is not the same as "verification", but rather points to a way of thinking about a solution (how can you verify something that doesn’t still exist?). And that solution is not absolute. It might be the seed to another and better solution. From my experience, this pattern is recursive.

In my next post, I’ll write about some tools and techniques which I use when writing unit tests up front, and which I hope will help you to better use TDD for your advantage. Until then, feel free to share your thoughts on the topic!

Recommended articles for this topic:

• Dave Astels wrote a nice article about Behavior-Driven Design and how it compares to TDD. I think the principles behind his article have more weight than arguing about the naming of such practices. Check out his article about A New Look At Test-Driven Development.
• Thought leader, Scott Ambler, has written a ton of articles about all things related to agile development and TDD. Two of his papers on TDD, Introduction to Test Driven Design and Quality in an Agile World, are highly recommended to learn more about this practice.
• The Way of Testivus is a cool piece of writing from Alberto Savoia in which he shares some funny and smart remarks about unit testing in general.
• TestDriven is a useful site about test-driven development in general (.NET, Java, etc.). Lots of news and awareness on this topic.
• And of course, Google is your friend for more writings on this topic.

JetBrains, makers of some of the best .NET development tools for Visual Studio, have released ReSharper 3.1 on this Christmas Eve. I have been using ReSharper since version 2.x came out, and I must say that it is very hard to develop without this tool. I don’t normally depend on a tool to drive my code, but this one is an exception, since it boosts productivity, quality and speed during development.

This new minor version provides a nice feature, Solution-Wide Analysis, which analyzes all projects in your solution looking for errors on-the-fly, without compiling it first. To enable this task, all you need to do is explicitly switch on the feature (make sure you have loaded a solution before enabling the feature), and then, after it analyzes your solution, view the list of errors in a dedicated window (Figure 2 shows you how to activate that window). You can also tell the analyzer to skip some files or folders (see Figure 1 for more information). Depending on the size of your solution and the performance of your hardware, this operation might take some time to execute (see Picture 3 for more information).

The most important characteristic of this feature is that you don’t have to compile the solution to get the list of errors, which can be of a great benefit for a solution consisting of a handful of projects which might take more time to compile than performing the Solution-Wide Analysis.

See what I meant by boosting a developer’s productivity, quality and speed? Check out the release notes for ReSharper 3.1.

Another cool gift from JetBrains is that if you purchase a license for ReSharper 3.1, you will get a free license for the next major release of the product, ReSharper 4.0.

Figure 1. ReSharper’s Solution-Wide Analysis window (new in version 3.1)

Figure 2a. Activate the Errors in Solution window

Figure 2b. This is the Errors in Solution window

Figure 3. The Solution-Wide Analysis operation might take a bite out of your hardware’s performance

If you’re a .NET developer that needs to call native functions from Windows API, you might be interested in the PInvoke.NET’s website.  According to the front page of the web site,

PInvoke.net is primarily a wiki, allowing developers to find, edit and add PInvoke signatures, user-defined types, and any other information related to calling Win32 and other unmanaged APIs from managed code (written in languages such as C# or VB.NET).

.NET developers worldwide can easily contribute to the community, sharing their valuable knowledge, whenever they have time to do so.

As defined by Wikipedia,

Platform Invocation Services, commonly referred to as just P/Invoke, is a feature of Common Language Infrastructure implementations, like Microsoft’s Common Language Runtime, that enables managed code to call native code in dynamic-linked libraries (DLLs).  The native code is referenced via metadata that describes functions exported from a native DLL.

For instance, if I need to call a function to shutdown or reboot Windows, then I’ll just select the user32.dll under the “Desktop Functions” section, then click on the ExitWindowsEx function.  Here’s a sample of what you might see for this function.

So next time you’re wondering how to call a native Windows function from your C# or VB.NET code, visit www.pinvoke.net, select the DLL where the function is located and follow the guidelines described in the web site.

Another way to access the Windows API is directly from within Visual Studio.  As a matter of fact, the web site offers a free downloadable PInvoke.NET add-in for Visual Studio so that you can look up and easily select the function you need.  This free add-in is provided by Red Gate Software, makers of ANTS Profiler and other great developer tools.  Here are a few snapshots of the add-in in action (the pictures are from PInvoke.NET)