Geeks With Blogs
Jeff Ferguson Irritating other people since 1967

A recent episode of .NET Rocks asked this very question, and listening to the episode made me consider my thoughts on the matter.

[Disclaimer: Some of this post may be interpreted as “beating up on Microsoft”. This is not my intent. I use Microsoft in my examples because Microsoft development experiences have been the totality of my professional career. The issues I apply to Microsoft can assuredly be applied to any other company out there.]

The short answer is “no”. I started writing software for Windows machines in 1989. Back then, I had a copy of the 16-bit Windows 3.0 SDK and the Charles Petzold “Programming Windows” Second Edition book (which I still have, thank you very much). I lived with window classes, message loops, and WM_PAINT messages, all in the C language. No one can look me in the eye with a straight face and say that .NET Windows Forms is harder. If you doubt this, I will give you a copy of the 16-bit Windows SDK and the “Programming Windows” Second Edition book and I will sit down with Visual Studio 2008 and Windows Forms. We’ll both set out to write a standard line-of-business application, and we’ll see who gets done first. Go ahead. I’ll wait. I’ll even give you a head start.

I recognize, however, that I can say that because I understand the toolset. I understand it, in part, because I have had twenty years of experience with the Microsoft tools and technologies. I have lived this life for two decades, and, because of that, my view of the software development world may be colored by my experience. If I take a step back, and consider what a person just coming into the industry might be facing, I recognize that their answer may be “yes”. It would be a legitimate response, and I can think of several reasons why someone with less experience may offer that opinion.

Too Many Choices Make It Hard
Microsoft’s myriad of competing technologies often have overlapping use cases, and it can be difficult for new folks (and veterans alike) to decide what technologies to use. Should my data access layer be written in ADO.NET, use the Entity Framework, or ASP.NET Dynamic Data? Should my collaboration work be Sharepoint or Groove? Should I use WPF or Silverlight Out of Browser? No one provides easy answers to these types of questions (often times because the answer is “it depends”). The choices can be daunting, and the ramifications of the choice can make or break a project.

Demo Code Versus Best Practices Code Make It Hard
Conference demos often showcase the state of the art in the Microsoft tools and technologies set. The demos are carefully designed to highlight a specific feature: perhaps of ease-of-use or a subsystem feature. These demos are designed to be performed quickly without regards to actual best practices. An example of this might be a button on a form with code behind that uses dynamic SQL to access some data. This works well for the demo, but the problem is that the sessions showcasing the demos are recorded for posterity and replayed across the Internet by everyone needing to get a basic understanding of a technology.

This video-based online review of the demo code works well, until the person stumbles across a blog post that tells them that code behind is bad, and dynamic SQL is bad, and not having a separate domain objects layer is bad. Where does this person go after watching the video of the canned demo? Have we confused the new folks by doing one thing in a demo and doing something else in blog posts? Are we compounding the issue by offering different ways to get the same thing done?

Lack of Mentors Make It Hard
Much has been made of the fact that our industry is terrible in the areas of apprenticeships and mentoring. It has been suggested that we, as an industry, put some journeyman program in place to help new people learn the craft. It’s a great idea, but I think we can do things now with what we have in place today before that comes to be reality.

I think us “experts”, or “veterans”, or whatever we want to call ourselves – and I put myself in this category – don’t do enough to reach out to those who could benefit from our level of experience. We are, frankly, all full of ourselves, and love to write about esoteric topics like “Building Your Own C# Compiler Using MSIL, Notepad, and the IL Assembler” (or, in my case, discussing the implementation of lexical analysis state machines). That’s fine, but who do we hang out with? Other experts! Our associates are people who also write the “Building Your Own C# Compiler Using MSIL, Notepad, and the IL Assembler” articles. Do we reach out to those who could benefit from what we know? Do we intimidate them? Are they afraid to reach out to us because we’re “so far ahead”? Are we leaving the poor folks who need to know how to get a Windows Form to talk to a database through a business object in the dust because we’re too busy writing about the internals of BizTalk 2009?

Perhaps we can change that. The next generation hangs out where we “experts” do not: in beginner’s forums, such as the Visual C# Express forums on MSDN. If they, for whatever reason, are “intimidated” by us, maybe we could take the first step by spending some time answering questions on those forums. Perhaps we can spend some time there, answering some “basic” questions and, along the way, imparting some of our knowledge to help the new people. It’s worth a try.

Hard For The Experts … Because We Make It Hard
As I look back on projects that have caught my attention for one reason or another, I wonder if we have brought some of this “difficult software” on ourselves. I have seen many projects become over-engineered, over-thought, and over-designed. I have seen many technical leads spend time on features that won’t be used in the initial version but are built because “someday, the customer will need this”. I have seen teams spend six weeks in requirements and design phases, over-thinking problems and designing the ultimate system with ultimate scalability and ultimate flexibility – regardless of whether or not that flexibility is in the customer’s time frame or budgets. Often times, we don’t build what the customers need, but what we think the customers need. Do we really know better than the customer? Is our over-engineering justified? Often times, the answer is “no”, but we, in our infinite wisdom, build huge scalability, flexibility, and configuration subsystems for design features that the customer may or may not ever use. Software may be “hard” because we over-think the problem and, in so doing, we make it hard.

Build what the customer wants, but no more. You’re not on site to throw technology at people. You’re there to solve someone’s business problem. Build the software that solves their business problem, but don’t build more than that. Don’t over-complicate matters that are already difficult.

Now, if you’ll excuse me, I’m going to subscribe to an RSS feed of the Visual C# Express forum on MSDN.

Posted on Friday, August 28, 2009 8:41 PM | Back to top


Comments on this post: Is Software Development Hard?

# re: Is Software Development Hard?
Requesting Gravatar...
Another approach is for experts to write beginner-focus posts on things like basic SQL, regular expressions, structured HTML, C# generic containers, I/O streams, etc.

Though the topics might be well "beneath" your expertise, coming up with engaging and creative examples, sharp presentations supported with good graphics, and simple concepts explained with clear concise writing is a goal most experts could get into. Doing all these things well takes a lot of work, even for an expert, but communicating well about your expertise is a fundamental part of being an expert. And with luck, you'll help lead some beginners into your sweet-spot of expertise where you can really wow them when they ask the right question.
Left by Sam on Aug 31, 2009 10:17 AM

# Software
Requesting Gravatar...
Here is a great chance to drive a large number of targeted visitors to your blogs and websites for free.

Submit your websites, blogs, videos to http://www.zillionsb.com and get 1000s of visitors everyday for free. It also helps your websites/blogs gain valuable backlinks.

Let the other bloggers cast their votes to push your posts up for a greater visibility. Enjoy free huge traffic to your sites.

Thanks

Sara

http://www.zillionsb.com
Left by Sara on Sep 03, 2009 11:12 PM

# Is Software Development Hard?
Requesting Gravatar...
I do not have software development experience at all. All I have is a University degree in IT and I would like to comment based on my knowledge and reflection.

If the requirements are clear, highly accurate, realistic and agreed by both the parties, then yes, go ahead as per the requirements.

Yes, doing more than what client want is obviously making it harder, over-spending and over-complicating the matters.

But, there might be the situations when clients do not know very clearly about what they are talking. Their requirements are not clear or thorough. They may not even foresee the issue which are obvious. In such a case the requirements team needs to actively participate and use their professionalisms in order to make sure right solution for the right problem.

It may be hard because of so many other reasons, which are not included here. For example, poor requirements, poor estimation of time and cost, and unreasonable ways of saving costs. For example, saving few thousands of pounds while developing a system can lead to a loss of ten or times more at the end.
Left by Durg B. Basnet on Sep 12, 2009 4:34 AM

Your comment:
 (will show your gravatar)


Copyright © Jeff Ferguson | Powered by: GeeksWithBlogs.net