How To Compare Files in VB.NETLink Round-Up for 10/05/07

Beware of These Three Software Development Blind Spots

October 4th, 2007

Here Be DragonsOne of the common problems we encounter in developing software is that it is difficult to completely know everything about a desired solution before we begin. Another is that sometimes we lose focus on what exactly we’re supposed to be building while another is having a too limited view of the project. Let’s take a look at these common blind spots that can plague a software project and how we can deal with them.

Losing Focus on the Solution

The saying goes, “When you have a hammer, everything looks like a nail.” When you have a programming language, methodology, third party library, or other tool that you enjoy using you can start to focus on the tool rather than the solution. Some developers do this when it comes to OOP, over designing and tweaking objects while the actual application development languishes. Others become consumed with a particular language, tool, or method and apply it blindly, assuming it’s a panacea for any and all situations.

The important thing is to never lose sight of the goal of producing a working application within a given timeframe. If your project is encountering schedule slips related to redesign or if problems or limitations with a particular language, tool, or method are becoming readily apparent, take a step back and evaluate what you’re doing. Do what it takes to get your focus back on developing the solution that is needed, even if it means scrapping a favorite thing.

Wearing Blinders

If you’ve ever seen racing horses, carriage horses or farm horses you’ve probably seen them wearing blinders. These pieces of leather or other opaque material prevent the animal from seeing behind them or, sometimes, to the side as well in order to keep the focused on the task at hand. Sometimes people who are too narrowly focused on a problem are said to have blinders on. In development projects, this can happen when programmers and architects ignore what interactions their application will have with other programs or the business processes of the organization.

This can be a very subtle blind spot to detect because often things will go very smoothly at first since the tight definition makes it hard to wander off the path. Problems begin to crop up when the new program is integrated into the whole software and business framework. For example, your application updates records in a particular table while another longstanding process deletes records out of this table. Or perhaps users find your program a roadblock to performing their jobs because they have to go out of their way to work with it.

To avoid this blind spot don’t allow haste, political pressure, or just pure laziness to limit your analysis and design to a narrowly defined set of criteria. Make sure you allow room for changes, even if it’s in a later release, to handle these unexpected situations. Some development methods make this kind of problem easier to avoid by involving users in the process but you still have to watch out for this blind spot due to its hidden nature that can sneak up on you.

Assuming We Know Everything

What is the scope of your ignorance? What is it that you don’t know and don’t know that you don’t know it? It is often said that in a given software development project of a reasonable size that only about 20-40% of the problem is known while the application is being developed and that known unknowns, the boundary between knowledge and ignorance, only accounts for another 10% or so. This leaves a whopping 50% or more of a blind spot that can come back to give us considerable trouble. So, what can we do about it?

The first thing, of course, is to make sure we, and people associated with the project, understand that we’re not going to know everything about the problem domain. Jim McCarthy of Microsoft refers to this as “lucid ignorance”:

It is essential not to profess to know, or seem to know, or accept that someone else knows, that which is unknown. Almost without exception, the things that end up coming back to haunt you are things you pretended to understand but didn’t early on. At virtually every stage of even the most successful software projects, there are large numbers of very important things that are unknown. It is acceptable, even mandatory, to clearly articulate your ignorance, so that no one misunderstands the corporate state of unknowingness. If you do not disseminate this “lucid ignorance,” disaster will surely befall you.

It is better to admit our ignorance and have a successful project, even if it isn’t a 100% success, rather than assuming we know it and have a project failure. Ultimately, our goal has to be to reduce the uncertainty gradually as we classify our ignorance and break it down into manageable pieces. But, we still have to be aware of the fact that we still won’t know everything.

Have you seen any of these three blind spots? Do you have any other examples of blind spots in the software development process? Let me know what you think by leaving a comment.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Entry Filed under: Project Management

Rate This Article:

Not That GoodCould Be BetterOKGoodGreat (No Ratings Yet)
Loading ... Loading ...

2 Comments Add your own

  • 1. Aaronontheweb  |  October 4th, 2007 at 11:33 am

    I think losing focus on the solution can be a major problem, as you mentioned. Sometimes I get so caught up using a new framework or control library that I start looking for new “nails to hammer” instead of building the house!

  • 2. jfrankcarr  |  October 4th, 2007 at 11:50 am

    Thanks Aaron,

    I’ve seen this happen on a number of projects, most often with methodologies or add-on frameworks or tools. It can be fun for a while but when no solution is being developed or the result is obviously flawed it is no fun at all for anyone.

Leave a Comment


Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed

Visit Me At My New Site, Programming In C#

Most Popular Articles

Highest Rated Articles


Most Recent Articles


 Subscribe in a reader

To subscribe by e-mail
Enter your address here

Delivered by FeedBurner

VB Opportunities