A few weeks back I noticed that Agitar software was winding down its operations. I guess that's business speak for going out of business, but for sale if anyone wants to come and bail us out. Jerry Rudisin, the former CEO, stated the primary reason for Agitar's demise was that the market was not big enough to support the kind of value business they wanted to build. I also remember reading a quote a while back by Alberto Savoia, one of the founders of Agitar where he made a blanket statement that people just aren't doing unit testing. I hope he is wrong.

Unit testing is the closest thing to a silver bullet we have in software quality. So why doesn't everyone writing software do it? Because to do it right, it takes a tremendous amount of effort, which equates to cost. And when faced with limited resources and a mountain of desired features, most decision makers will choose features over quality every time because after all, features sell software. I am as guilty of this as anyone. Ideally, we would have >95% code coverage in our applications, but we don't. So how does unit testing improve quality so much?

1. It makes developers think about more than just making their code work. It makes them think about how to break it. And when they do this, they write better code.
   
2. Code is executed in atomic units while it's developed, increasing the chance that when everything is integrated together, it might actually work.

But the BIGGEST and BEST bang for your buck you get with unit tests… you get to know when changes break your software. REGRESSION! That's the big bang baby. That's what makes unit testing worth the investment.

Software is iterative. Release early and often. Iterate. Let your users tell you want they want, and then give it to them. I am sure you've heard that before. And it's great advice. But if you are trying to make software with 0 quality defects, or in user terms, no bugs, this iterative tactic works against you big time. ANY change to released code is bad and there better be a good reason for the change. This is a really hard point to make to the less experienced software gurus, who think if code looks bad, doesn't conform to current coding standards or could obviously be constructed better, they should just change it. NO! Any change, as benign as it looks, can break stuff. So then how do we make changes without killing the app? UNIT TESTS.

A good battery of unit tests is your ace in the hole. If you have them, maintain them, and protect them, unit tests will allow you to iterate and maintain a very high level of quality in your product over time.

So are people really not doing unit testing? I respectfully disagree with Mr. Savoia. I think they are. We are. I stated that to do them right requires a tremendous amount of effort. Agitar's problem is not market size. You simply cannot build (or buy) a tool that will do this for you. We are not talking about spell or grammar checking here. That's what FxCop does, to a certain degree. Unit testing done right requires simply using the tools that are readily available such as NUnit or MSTest and taking the time to write the tests that execute your code. When you do this, you will write better code. You focus on the edge cases. You think more about what the target code is doing. When you do this, you give your application that ace in the hole that allows you to iterate without significant quality issues. And this is why unit testing is profoundly worth the effort.

I have searched far and wide on the internet looking for someone saying something good about Windows Vista. It's a chore. It's not out there! And if it is, it's buried deep in the muck of negativity. So I thought I would buck the trend.

"I like Windows Vista"

                Brian Haas

There. I said it. That wasn't so bad. I haven't had to duck under flying objects yet.

I have been using Vista on my workstation for a month now and I can honestly state that most of the negative press is a bad rap. It's almost completely unjustified. Through all of my browsing I have read three consistent themes on Vista.

• No compelling reason to upgrade from XP
• Incompatibilities abound
• Extremely poor performance

And countless negative rants that say nothing concrete except that Vista stinks and Microsoft is doomed. Hold the parachutes. I don't think I'll dump my Microsoft stock just yet. Instead, I'll offer my opinion on these themes.

Compelling Reasons to Upgrade

I can't really disagree with this as a principle. But this is only because XP is a pretty darn good operating system, and this is not a knock on Vista at all. For me, the catalyst for change came when my workstation died a horrible death. Through hardware failure I was forced to upgrade my PC and if I were going to make the Vista leap anytime soon, this would be the time. We are in the business of creating software and more and more customers are running Vista so it does make sense for us to use Vista. And there's no better guinea pig than me. I am the only one here now sitting in front of Vista full time, but we all have experienced Vista over the past year in virtual machines while testing our software. Though I have not personally seen all the bad, bad experiences so many people have documented, the constant negative information has had its effect on me. Without a professional reason to be interested in Vista, I wouldn't have upgraded. But now that I have made the jump, there are some features of Vista that I really like and I expect I'll find more as time goes on.

1. The Start Menu

I really like this change. The feature I like the most is the automatic search of the start menu. I never dig anymore. I just start typing.

2. Previous Versions

Also known as Shadow Folders in Windows Server 2003. This feature lets you recall previous versions of documents simply by right-clicking and selecting the Previous Versions tab. I don't know if this is available on all Vista versions, but in Vista Ultimate it's just there. Apple must have thought highly of this feature as well since their Time Machine feature accomplishes the same thing.

3. System Search

Credit indexing as searching a Vista hard disk is extremely fast. I know XP has indexed searching too, but not out of the box.

4. Aero

I like the glass. I like the eye candy. Looks matter.

5. User Account Control (UAC)

Yep I like it. It took a little getting used to and we have had (and are still having) to write code to properly support it in our applications, but it is a good thing. Prompts really don't interrupt me very often. Between the UAC, the Windows Firewall, and our hardware firewall I have wondered whether Anti-virus software is really even necessary. It's here, but I have wondered.

Are any of these features compelling enough to upgrade? I don't know. There is certainly cost involved with upgrading even a small business. But what I do know is that four weeks into my leap, I have not found a compelling reason not to migrate as system hardware is upgraded. And I don't miss XP.

Incompatibility Issues

When making decisions on Vista between compatibility and security, it seems the folks at Microsoft always chose security. This is a 180 degree turn around from past Windows versions. But when for years a company gets beat up and beat up and beat up on how insecure their products are, they start to take it seriously. Well I think Microsoft is damned if they do damned if they don't. They just traded their insecurity bashing for incompatibility bashing. The jury is still out, but I bet Vista's tarnished image will cost them faaaaar more than their previous security woes. What's ironic is if the world really cared so much about security, they should be flocking to Vista. Yeah, yeah, I know. We have tools to secure the insecure windows world now and MS has already fixed most of XP's security holes. The beast we know is better than the beast we don't know. With all of Vistas negativity, just knowing that most design decisions from top to bottom likely favored security, I have the utmost confidence that Vista is far more secure than XP. Not totally secure, but far better than its predecessor.

I won't give MS a complete pass on incompatibilities as they are as guilty as the vendors they now seek to point the finger on. I know of one application (that I built) that will not run on Vista because of Microsoft's decision not to support their own Microsoft database engine (MSDE). Sure the owners of that application could migrate to SQL Express and they probably will if they haven't done so already, but it will cost them.

I did have to replace my printer because of one particular printer manufacturer who obviously chose not to support their customers. This was probably the most disappointing topic of my upgrade. My all-in-one printer worked great albeit a little slow. This came as no real surprise as I had to actually purchase the last updated drivers for XP. This is the last beating I'll ever take from Hugo and Paul. I have no worries though, because my new Brother came to the rescue.

But as for the incompatibilities that I was really worried about….No big deal! I use a lot of software and everything worked, with the exception of VMware, which is pretty low level. And I mean everything, right down to my 8 year old Photoshop 5.5. Utilities, applications, console apps. Everything, but my printer and VMware. Some applications required checking the box to always run as administrator but I expected worse. Much worse.

Poor Performance

This one will be short. Not true. Maybe if I ran XP on this hardware it might be faster, but I don't wait for much. Of course, I am a programmer, designer, entrepreneur, reader and writer of stuff. I am not a gamer. And for folks like me who constitute the bulk of PC users, Vista is not a dog. At least not on today's comfortably equipped hardware.

I like Windows Vista. It's been said. I am sure I there are more like me out there…somewhere. So now that it's been done at least once, maybe someone with a louder voice than mine will pick up this trend and say something good about Vista.

I love studying software development methodologies. After all, what is a methodology? It's someone's attempt to draw on past experiences to define a systematic process that will lead to fewer mistakes in the future. That's not Webster's definition, its mine. Most everyone else would probably mention "repeatable success" in their definition. I like mine better because I'll let you in on a little secret… are you ready… here it is… making good software is hard. And no methodology alone will lead to repeatable success. At the very least a critical analysis of every completed project should be done, and your methodology tweaked from lessons learned. The trouble is, too many teams don't even bother to do that. Critical self reflection is not something we as humans do very well.

Don't read me wrong, software teams need to follow a methodology, whether it's your own or someone else's. And there are no shortage of documented methodologies for you to choose from; Waterfall, Agile, Extreme, Scrum, RUP, Adaptive Software Development, Lean Development, to name a few. While repeatable success with an arbitrary team is the goal of a methodology, it is a lofty goal. My own experience says success is dependent more on people than methodology. This explains why some teams inexplicably succeed without any identifiable methodology. Good teams do their very best to improve with each project, and as a result their methodology improves.

Through the years I've been involved with many projects in varying capacities that utilized recognizable methodologies. I have my favorites, as I am sure you do. Methodologies are a lot like politics. You have extremes in Waterfall and Extreme Programming, with overzealous advocates who seem to shout with the loudest voices. And as with politics, the majority of us advocate for something somewhere in the middle. When I compare methodologies across the spectrum, the most significant difference between them is the degree of iteration. Software, by its very nature, is iterative. Something as abstract as software must be iterative. For most non-trivial software systems, you have to build it before you see its flaws, and I'm not talking about bugs. Conceptual flaws that are hard to foresee. Make no mistake; it's the risk of conceptual flaws that iterative software development seeks to mitigate. This necessity is all too often cloaked by descriptions of being "adaptive to change" in business. Business does not change near as fast as our perception or understanding of the business. And if you are building software, you are likely trying to automate, streamline, be more efficient/responsive, analyze, quantify, evaluate. For any of these business goals you better darn well know exactly what you are trying to accomplish before you try to create software. Far too many projects start without this understanding.

So how do you gain this understanding and build software that works? Iterations. For businesses that are well understood, methodologies with fewer iterations will work, regardless of the goal of the software, or even the size (in development effort). This is because a good, unambiguous specification can be written about something that is well understood. And developers can write good software from good unambiguous specifications. But without complete understanding, any software development process with few iterations will likely fail, and that is because the spec will not be very good. You just can't spec a process that is not well understood. The team will try, they will fill a document full, review it, and sign off on it because it will mention enough of what the decision makers really want out of this new software system. The developers will get it, scratch their head, ask a lot of questions, and then go build software, most likely filled with many conceptual mistakes. These projects performed in a Waterfall type methodology will always fail. When the software is delivered, it will be all wrong, and even if management is steadfast and funds the corrective iteration that fixes the software, the project will cost twice as much as forecast and will still be considered a failure. The less understood the business, the more iterations you need. If only it were all just about creating good software…

Managers and decision makers want to know how much a software project is going to cost. How much money will you spend up front just to gauge the risk? How solid are your estimates? Methodologies play a big part in these discussions as well. Folks I don't care who tells you otherwise, any software estimate made without a complete written spec is not an estimate at all. It is a guess. Sure, the more you guess the better you get at it, but dispense with the baloney and call it what it is. There is a reason why software estimating is often referred to as a Black Art. Software is extremely expensive to create and business people don't like to take risks based on a guess. Software methodologies must not only attempt to manage creating the right software, but it must also manage time and dollar estimates.

So how do you determine the best methodology? For established, continuous development software teams, I think it is their methodology. Sure they may have started from a known base, but with every development project they refine and improve to fit their product, environment, and people. So it is their methodology. But for new project development and consulting teams, what you do must be based on the specific project and its goals. For well known business practices, a methodology with fewer iterations and a heavy up-front specification process is best. These types of business scenarios are really easy for an analyst to identify too. Here's a real quick litmus test. Can the subject matter experts answer your questions clearly? Does every answer start with "that depends on…"? Ask three subject matter experts the same question, and compare their answers. For projects where the goals are less understood, go agile. And that means more iterations. Spec-code-test, do it again. This works because subject matter experts can see, drive, and evaluate software so much better than they can a spec doc. So give them software and then ask what needs to be changed and added. Do this enough times and you'll end up with conceptually correct software. Of course this too is dependent on the subject matter experts actually taking the time to perform an honest review. It pains me to say, but sometimes even that is extremely difficult to get accomplished. And without it, agile is no better than waterfall, at least from the goal of conceptual accuracy and risk mitigation. Everyone is busy this is true, but building good software is a team sport, and everyone on the team must play in order to achieve success.

So what does all this mean? Adopt a methodology that matches the business understanding of the project. Think in degrees of iteration. For most new software I tend to lean towards agile approaches, but don't get caught renaming your utter lack of any methodology for being agile. This is way too common. For well known business goals or projects porting legacy systems to newer technology, I would lean towards an approach with fewer iterations. There's very little risk there, so take the time to write a single complete spec. For your upfront efforts you'll end up spending less money in development.

Regardless of your chosen methodology, here is what you need to create conceptually accurate software.

1. You need a spec.
2. You need reviews by people who know what the software is supposed to be doing.

Do you have a spec? Any Spec? If not, you don't have a methodology you are flying by the seat of your pants. Weekly meetings, heck daily meetings, and whiteboards are fine, as long as the decisions are captured in the written word. If chicken scratch on the back of a Quiznos napkin is the best you can muster, photocopy it and distribute it to the folks that are going to create the code. You'll end up spending less on development for your efforts.

Get the reviews. People prefer to review software over documents. After distributing a specification doc, I once received feedback from a guy that our client identified as a subject matter expert for review purposes. His feedback was, "It's difficult for me to determine if this would work or not based on this document, so I'll have to reserve judgment until I see the software." Gee, thanks for the help. I asked for a new subject matter expert. You need that feedback though, so get it any way you can. The analyst or developer who thinks they know more than the client does is in dangerous peril. Ask yourself who are you are building the software for and who will determine whether it is right or wrong?

Software development methodologies exist to help us succeed in a difficult endeavor. They are no silver bullet, but just making an attempt to learn from past experiences and applying those lessons learned in future work will lead to greater software success.

Ah the thrills of working a dream. Being my own boss. Creating a company "of the people, by the people, and for the people" so to speak. A company that's not cut from the corporate or venture capital mold where every decision is profit motivated. How fun it is. No two days are the same. Such is life trying to build a software company from scratch with nobody's money but your own. Many folks would call my company a Micro-ISV. A term coined by Eric Sink, founder of SourceGear. I am not a big fan of this term because of its ambiguous perceptions, but nevertheless, the term does accurately describe my available resources. And with loads to do and micro resources, you roll up your sleeves and get busy. You learn to live by these ten words.

If it is to be, it is up to me.

Perhaps had I seen Neil Davidson's Micro-ISV survey before I started this gig I might have reconsidered and stayed marching to the beat of the corporate drum. Yet even in the face of undeniably bad odds, I am hopelessly optimistic because I firmly believe that with hard work, talented people, strong focus and persistence, success is inevitable. This belief doesn't help my resource problem though, and as a result, I do lots of things myself, both technical and non-technical.

Because I do so many different things, I've come to wonder exactly how I would title my work. Thinking purely technical, I would say I am a jack of all trades, which has me wondering… is knowing a little about lots of technical areas better than knowing everything about only one particular technical area?

It's interesting when I discuss software with corporate developers. Many of their issues have to do with people, opinions, and pecking order. Corporate, big money development involves lots of people, lots of specialties, and lots of individual interactions.

The list of specialties involved in creating high quality software is pretty long.

• Analyst
• Architect
• Application Developer
• UI Developer
• Technical Writer
• Graphic Designer
• Project Management
• Web Developer
• Tester
• Deployment Engineer
• Product Champion
• IT Support
• Technical Evangelist
• Database Admin

And the list could go on, even into sub-specialties. I was discussing web development the other day with a friend and I asked a question about JavaScript and AJAX. His response dumbfounded me when he told me he didn't do JavaScript. He writes Asp.Net. The browser guys write JavaScript. This is shocking when I contrast it with a day in my world.

I am not a web developer… but I write a lot of Asp.Net code.

I am not an analyst… but I write a lot of specs.

I am not a tester… but I do a lot of testing.

I am not an IT guy… but I do a lot of server stuff.

So what's better? I think it's less about what you are responsible for, and more about what you are interested in and pursue knowledge of. A person who knows only JavaScript, and is not interested in anything else would not be very useful here. However, if that person knows far more JavaScript because of previous duties and responsibilities, but also knows about Asp.Net, IIS, and Data Access, we might have a place for them.

Speed is what you get with a highly specialized technical expert. I could write anything in JavaScript, but it will take me longer than it might take "the browser guys". Depending on the task, far longer. At $185/hour, I expect that many companies value speed over everything else. It goes back to that profit thing. But take into account the cost of the human interactions between specialists, and those efficiency savings start to get lost.

With technical tasks success or failure is pretty easy to spot, regardless of how long it takes to complete. Whether or not it works is usually easy to judge. So if all I get is five people to create a new software application, I would take 5 jacks like me over five specialists any day.

With non-technical tasks however, it's not that simple. The harder it is to assess the success of the work product, the greater the need for a specialist. I used to think that a smart developer can do almost anything. I still do for the most part, but let's just say that in the 15 months since I launched Kinetic Jump, my opinion on certain non-technical tasks has changed. But more on that next time…

Brian

Can doing things right, bite?

We released our first product, AppLife Update, in late June. This product is an automatic updating solution for .Net that makes it really easy to add automatic updating features to any .Net application. Of its many features, one is that you can apply an update without needing administrative rights. We accomplish this through the use of a Windows Service that can execute an AppLife update package under the security context of the local system. To provide this feature securely we did a lot of work. We require administrative permissions to register any given application before it can use the service. We use RSA public/private key technology, we lock files, we double validate both inside and outside the service, we do lots of things. Somewhere, in all of that security decision making, we decided to sign all of our executable with an x509 Authenticode certificate. Seems pretty benign right? Heck, if you read the Windows Vista Software Logo Spec 1.1, you'll see that Microsoft thinks it's a good idea:

All executable files must be signed with an Authenticode certificate. This includes files with the following extensions: exe, dll, ocx, sys, cpl, drv, scr
Limited waivers may be available for 3^rd party redistributables when singed versions are not available.

Before going out and buying our certificate, I read lots of information about Authenticode signing and it just seemed like the right thing to do. Heck the only real decision I felt I had to make was whether to pay more for a Verisign certificate or go with Thawte. We didn't. (I don't really understand that difference, especially when Versign owns Thawte, but that's a topic for another day. Perhaps the power of a brand?) Signing our assemblies just seemed like the right thing to do. So we did. Carte blanche. All exe files were code signed, along with msi's and msm's.

And when we were all done, we tested, tested and tested some more. We covered just about every potential environment we could muster in-house, and we found beta testers out there "in the real world" to run updates. We were updating in corporate environments, in small business environments, in home environments. Our solution just worked. So we shipped.

So what's the problem?

Along about the end of July we received a support email informing us that a guy in Germany couldn't install our software. He had 64-bit hardware running German 64 bit Vista. Not knowing what his issue was, we went to work trying to solve it. Whenever he tried to install our software, our windows service would fail to start. Looking into the msi logs, we found:

Error 1920. Service 'AppLife Update Service' (KjsUpdateService) failed to start. Verify that you have sufficient privileges to start system services.

We tried hard to reproduce his issue and we couldn't. We did find some issues with our product and 64 bit operating systems, and our product is now better for that, but no matter what we tried, we just were not able to reproduce this. I also got really good at navigating to the control panel and event logs on non-english Vista. This might come in handy some day, if more than a handful of customers ever actually make the move to Vista. This person then discovered on his own that if he disabled his network card, the service could start. Inquiring about this, we learned that his company used a Ken firewall system that is common in Germany, but does not have an English version. After spending loads of time on this and seeing the evaluator's enthusiasm to get to the bottom of the issue disappear (and who can blame him), we gave up. Our best guess at the time was some incompatibility with their firewall/proxy system was causing our service to fail. We really couldn't do much more because after all, we kinda needed him since we were never able to reproduce it.

Then in September, another evaluator reported a similar issue. He too was in Germany, but didn't have any unfamiliar networking software, but they were behind a proxy server. It was then that we first knew that we had a real problem and good or bad, we were happy to have another "tester" since we knew we hadn't fixed it and still couldn't reproduce it. So we littered our service code with additional exception handling and sent him a custom version of the service. He still couldn't install and we weren't getting any information out of our exception handling. This was very odd. It just seemed like either our code was not executing or something was hanging. We didn't have to look through much code since the service really does very little work on startup. One thing it does do is create an IPC Remoting channel. The IPC Remoting channel is based on named pipes. So we went into dissecting every bit of the framework IPC Remoting channel, looking for anything that might fail when executing under the local system account, or in a way that hangs the process. This lead us nowhere, except a better understanding of the framework IPC channels.

This story ends with the final realization that our code was likely never even being entered and with the proclamation that Google really is magical. I really don't remember how, but I found this blog post using Google.

http://blogs.msdn.com/shawnfa/archive/2005/12/13/502779.aspx

And in there it talks about Certificate Revocation Lists and how the .Net framework attempts to verify a certificate and how this can be time intensive. BINGO! And I was not even looking for anything related to code signing.

The revelation was found.

Loading a code signed .Net assembly could take a long time if network access is being blocked to the security profile that is loading the assembly.

We rebuilt the service without signing the service executable and sent it off to our evaluator. Problem solved. After this, I went back and re-read about code signing, and the potential for this issue is just not presented anywhere in the educational literature that I could find. So file this little nugget and think about it anytime there is an inexplicable pause in loading a .Net assembly. Is it signed?

Through all this, I did try to enlist the help of others, but when you can't reproduce an issue, it's really hard to ask anybody to give the time of day to solving it.

And even after discovering this, we made boneheaded mistakes that lead to further issues by just not thinking. This week another evaluator, amazingly again in Germany, couldn't perform an elevated update using the service. It turns out that we missed removing the code signing step on assemblies that the service interacts with during an update process. I felt pretty stupid this week.

What's even more surprising is what the Framework does after the certificate validation fails. The assembly fails to get a specific attribute, but otherwise loads and executes just fine. In both of our problems, the actual reason for failure was timeouts waiting for activity that should not have taken so long. If our time out thresholds were longer, the process would have worked, but been unnecessarily delayed.

So finally, after almost six months since the first report of an issue, I think we have this problem completely solved.

We still code sign our primary executable and our installers, but that's it. We do this primarily because we distribute our software exclusively over the internet and we want to instill confidence in our products. Also, the worst that could happen is some users might experience a delay before our application starts.

The lesson learned here is a tough one. We decided to sign our assemblies based on a desire to follow Microsoft suggestions for trustworthy computing and doing the right thing. I now know that doing the right thing can bite. Hard.

Brian

If software specs are so important, why do so many software teams skimp the most on specifications? Here's the politically incorrect skinny.

• It's very difficult to do it well
• It requires fighting with other people for their time
• Those people you fight with don't think you listen to them, so they don't want to help
• It requires time and money that managers don't want to spend
• Nobody finds it very entertaining, so they are never "in the mood"
• Perception is reality, and creating software, any software, is perceived as progress. Creating documents is not.

We all do this. We all skimp on specifications. To what degree we skimp is the differentiator. For most organizations, about 50% of all software projects fail. Projects fail for lots of reasons, but a consistent theme in post mortem analysis is inaccurate or incomplete software specifications. Is there truth to this, or is it just easier than saying our ideas suck? If there is truth though, we should conclude then…

Improving specification activities is the single best way to improve your software development project success probability.

And this should make logical sense too, since no matter how good you are at creating software, if you are creating the wrong software, it's irrelevant. But… you could also logically conclude that too much effort in specification is also bad. After all, you do have to eventually build something. So seek to find the balance, but don't skimp.

Everything in Software is Iterative

I do not think that it is possible to fully specify a software product before it is built. And most people agree with me too, as nearly all respected software methodologies involve some level of iteration.

Spec, Design, Build, Test. - Do it over again until you run out of features to add or money to spend.

Everyone does this. The primary difference between methodologies is merely the size of the iteration. Some like them big (think waterfall), some like them small (think agile). But regardless of iteration size, are your spec docs changed during an iteration? Are spec changes controlled? Here's a test to help answer that question. When you finished your last iteration, did your specification match the product? If it does, it was either a really good spec or it was alive.

The Difference that a Living Spec Makes

If your spec has been properly maintained, then it is alive. It's a living document. It has an owner. Someone on the team who actually cares about it enough to feed it, water it, and make it grow. When you update a spec, then design and build against the change, your changes are more thorough. That's because when you open the spec, you are again immersed into the application as a whole, not just the specific issue that brought about the need for a change in the original spec. The cross references and related functionality are again brought to the forefront of your mind and you start to analyze the change in its entirety and how it affects all of the application stakeholders.

The importance of keeping a living spec increases with the size and complexity of your software. But even if your team is me, myself and I, you will create better software if you write specs and maintain them throughout the life of your application.

So don't neglect your specs! Give that doc a pulse and you will end up with better software.

Brian

Mistakes, Criticism & Initiative

It's no secret to anyone who has ever built a software system that the task is difficult. As an aside, it's the challenge that is presented every time I start a new project that makes this profession so fun to me, but back to the topic. I've had folks tell me that software is not hard, but these opinions are often premised on their work of writing Excel macros, or perhaps dabbling at modifying an existing application slightly. I have even had supposedly technical people ignorantly question my estimates on implementing new features by asking me telling me that I should be able to just "write a little script" to accomplish the feature. What do you tell those people? No.. what I am referring to is the task of creating a new application or feature from scratch that users actually like and stands the test of future change – by another developer.

After acknowledging that there is at least some modicum of difficulty in this endeavor, it should come as no surprise then that mistakes are often made. Evidence of this is all too clear to anyone following tech news. The sheer volume of negative software news is disheartening, though I truly believe that many of the articles I read are more influenced on "software politics" than any real interest in accountability. I especially love the articles that pose those questions like "would we as consumers put up with a car that blue screens every time the turn signal is turned on…"

You can read tons of books and articles about software and quality. We have methodologies, testing, code reviews. CMMI level n's. More methodologies, different tests and even more reviews. Throw in design, specs and better up front engineering efforts. Put a little of all this theory to practice and you might come to the conclusion that quality software is possible, but not easy to accomplish. Even with all of the activities in place to improve your chances of repeatable software success, mistakes will be made. And that's what I really want to talk about.

Mistakes in a software project come in many shapes and sizes.

• Specification Mistakes. Fred Brooks said it best. "The hardest single part of building a software system is deciding precisely what to build". Many times I have built exactly what the spec said, only to discover much later that it was wrong. The unfortunate part of these mistakes is that engineering often take the brunt of the blame and criticism for specification mistakes that they had little or nothing to do with.
  
  
• Design mistakes. These mistakes are often not immediately apparent until performance and maintainability issues crop up. They usually manifest themselves late in the project, where fixing them becomes increasingly expensive.
  
  
• Coding errors. These are probably the easiest mistakes to mitigate through testing and code reviews. Still, they too often slip through, I think mostly due to sheer opportunity count.
  
  
• Deployment problems. Failed installs. Dealing with incompatibilities, suspect or compromised systems, etc. These issues are not insignificant. If they were, we wouldn't be forced to use so many less than stellar browser based applications.
  
  
• Bad personnel and platform decisions. Sometimes these mistakes will sink a software project the fastest.
  

What happens when mistakes are made?

When a mistake is discovered, my experience tells me that the first question many managers immediately ask is "who did it?" Something is out of whack and it shouldn't be. There must be someone to blame. And sometimes blame is good. The kind of mistakes that happen as a result of a lack of attention to detail are sometimes best handled through the blame game. Some harmless egg-in-face to keep the team on their toes. Checking in code that won't build, thus breaking the build process is an example of this. Find the knucklehead, and make sure everybody knows who it was. But what about mistakes that are harder to discover and come with larger consequences. What about a bug that slips through testing and happens to rear its ugly head just as the president of the company is presenting the newest features to a room full of prospective customers? Is a "head gonna roll" so to speak? Not in my company.

Instructive, Constructive and Destructive Criticism

The only reason to criticize someone at all is to motivate a person to change their behavior. Yet it seems inevitable that when things go wrong, emotions take over and managers often say things that were not thoroughly thought out, and when this happens, destructive criticism ensues. As a manager, strive to be constructive and instructive, not destructive. First things first, find out what really happened. All too often the wrong person or group bears the brunt of initial criticism. Apologies later cannot repair the damage that has already been done. Once you know what really happened, if there was a person or group that exhibited behavior that you think needs to be changed, by all means do it in private. And once you're in private, here are a few more tips.

• Avoid the word "not". Not is bad. Not will not get you results. "That's not right", "That's not how to do it", "You should not have done that". Use better ways to get your point across. "There might be a better way", "Maybe I could have been clearer when we discussed this", "There are many ways to accomplish this, and perhaps this approach would work better".
  
  
• Think before you say - "You should have [fill in the blank]". Hindsight is 20/20 and pointing out errors in retrospect is easy even for stupid people. Find a better way to point out how the doer of the deed could have done it better.
  
  
• Have patience. Never take away the mouse or rewrite someone's code during a code review. Nothing is more disrespectful. Either have the patience to instructively discuss how you think your ideas will improve things, or just leave it as it is.
  

So why worry about all this? What, besides hurt feelings, is the result of destructive criticism?

Lost Initiative

Quite simply, people will not display any more initiative than absolutely necessary if they think their efforts might lead to destructive repercussions. They will not strive for a better way to do things. They simply will stop trying or suggesting anything new. Marching pays the same as fighting so-to-speak. Innovation cannot exist without initiative. And if you're working in the world of competitive commercial software products, an innovative nugget from even the most junior member of the product team just might make the difference between the success and failure of your product.

Now by chance, if you have ever worked for the 3M Company, you're probably thinking to yourself - wait a minute… I've heard this before. That's because you have. I didn't come up with this stuff, but I wholeheartedly agree with it. William McKnight built 3M to prominence in the 50's and 60's with this basic rule of management:

"As our business grows, it becomes increasingly necessary to delegate responsibility and to encourage men and women to exercise their initiative. This requires considerable tolerance. Those men and women, to whom we delegate authority and responsibility, if they are good people, are going to want to do their jobs in their own way. 

"Mistakes will be made. But if a person is essentially right, the mistakes he or she makes are not as serious in the long run as the mistakes management will make if it undertakes to tell those in authority exactly how they must do their jobs. 

"Management that is destructively critical when mistakes are made kills initiative. And it's essential that we have many people with initiative if we are to continue to grow."

3M is not a software company, but I think Mr. McKnight's principles apply especially to software companies.

Software development is a field where we define "crap" as other people's code. That's pretty critical. Where managers too often have very little respect for the difficulty involved in the software development process, or the people that create the software. Combine this mindset with the many opportunities for mistakes in building software and you get… destructive criticism that leads to less initiative and no innovation. And that's the very stuff that a software company needs to be successful.

Brian

Chocolate or Vanilla? That's the question I posed to 24 kindergartens last week as I passed out holiday cupcakes to my sons class. For the record; 14 chocolates, 10 vanillas. Now a statistician would tell you with much bravado that clearly chocolate is superior to vanilla by a commanding 16.7%. A chocolate connoisseur might latch on to that statistician's conclusions and add a few choice words such as rich, delicious, moist, or dark to his commentary and be very convincing to the unbiased observer. But the real truth is that the correct answer to this question is purely a function of the person. Some folks just like chocolate more. No further analysis required. The question that I pose is this. Can we say the same for development platforms?

What would be the results if I asked 24 software developers, at random, whether they prefer .Net or Java. Clearly this question must be more than just a matter of choice. Clearly there must be some level of superiority here. Be it in inherent capabilities, tools, or hardware. Based on all the "statistics" I have seen over the years, I would guess that the answer to my question would yield a near even count for both platforms. Could it be that the choice of development platform for a new software project be as arbitrary to its success as choosing a chocolate cupcake over vanilla? Don't bet the farm.

Barring any technical prerequisites that would preclude one or the other (yes, they do exist), I stand by my prediction of results. Why is it then that about half of the professional development world writes in Java and the other half .Net? I think it's because both platforms are viable for most software solutions. The differentiator, just like the cupcakes, is in the people. The investment it takes to become really good in a particular development platform is great. And with technology, personal bias is all about knowledge of a given platform, or lack of knowledge of the alternatives. And when you look at a developer's career, they are never more eager to sponge up technology details than in the beginning. So it is with very few exceptions that a developer doesn't answer my question based on their developer roots. What platform were their first projects on? In a previous life, I worked a little in industrial automation and that world has their technology players as well. Multiple vendor platforms with specific strengths and weaknesses, but overall pretty equal. Engineers in that world have their preferences too. Modicon, Allen Bradley, Siemens. Their personal preference can almost always be mapped back to their first project.

For the record, I am a .Net guy. I am a .Net guy because I "grew up" using Microsoft development tools. C++, VB 4-5-6, Asp, Interdev, VS200x. Yes I have also written java code, but very little. Could I architect a good Java solution? I know I could. I know I could because I am a good developer. Classes are classes, patterns are patterns, and languages are just syntax, blah blah blah. Besides, I love the curly brace {J}. But I also know that I could build a far superior .Net solution in less time. And it not because I think .Net is far superior to Java. With .Net, I can just do. With Java, I'll know what I want to do, and then have to look up how to do it.

So what difference does all this make? Make your platform decisions based on your people, or your people decisions based on your platform and your software projects stand a much greater chance of being successful. And if this stumps you, find a 5 year old and offer him a cupcake to explain it.

Brian