Writing software is too easy these days.
Since it's so easy, there is a bunch of bad software out there.
It's easy to write bad software. It's hard to write good software.
Everyone needs software these days. From the home consumer to the large
enterprise. For the home consumer, we
have shrink-wrap software developed by large teams, such as Microsoft Office,
Quicken, etc. As a business grows,
however, it’s more likely to hire or contract some programmers to write some
custom software to drive efficiency in the business.
This is where the “software is too hard/easy” argument comes
in to play. Some complain that software
is too hard.
Paul
Reedman in 2004 blogged how he thinks software development is still too
hard. Paul focuses on Java
technologies. He complains that research
has focused on the language as the way to solve problems instead of the tools.
Steve at
furrygoat.com ponders whether writing software is too hard because it’s a
little difficult to learn how and it takes some effort.
Rocky
Lhotka declares that software is too hard.
He laments that software developers have to worry about similar tasks
from project to project (plumbing). In
this article, the tools are to blame because they provide too much flexibility
(require too many decision), whereas a good tool would reduce the creation of
software to merely configuration (my interpretation).
I declare that writing software is too EASY. For the semi-technical
folks that need to make something to help out the business, we have tools like
MS Access, Excel and even word macros.
You can do some pretty cool stuff with MS Access using linked tables to
SQL Server!
When it comes to custom
software, it requires a properly skilled person. Software is a craft. It’s bordering on engineering and overlaps as
well, but it still has some maturing to do.
An unskilled person is dangerous when attempting custom software. There are plenty of products a company can
buy and then let the semi-skilled office worker configure it, but custom
software is just that, custom. You
wouldn’t have a custom chopper built by someone who wasn’t very good, would
you?
Tools today make
custom software too easy to develop.
This statement may seem controversial, but I believe it. I’ve seen too many unskilled people take a
programming tool and throw together something that seems to work initially. The business folks can’t tell a fraud from an
expert or evaluate the work, so they use it and then feel the pain later when
they actually have to maintain it.
Software isn’t a toy. You don’t “play around” with writing
software. Companies rely heavily on the
custom software they pay for. My company
could be sued out of business if the software screwed up. Software is serious. From bank transactions to supply lines to
taking orders on the web. The business
relies on the software. If it’s buggy,
the company could be losing money and not even know it. If it was developed by an unskilled person,
it’ll be hell to maintain, and it’ll suck money out of the company later.
There’s been some talk on different types of “programmers” –
Mort/Elvis/Einstein (most recently by Scott
Bellware and 2nded by Sam
Gentile. This thought is that these
types of programmers aren’t valid anymore and that there needs to be one type (the good type)
The only type of
programmer should be the good type.
This is what it comes down too. Companies should not trust an unskilled
person to be a programmer for them.
Ultimately it’s the managers decision, but it also their
responsibility. A manager should know
what a good programmer is. That is a big
problem in a lot of companies. The
management has no way to know if a programmer is good or not. What happens is that an unskilled person
throws a piece of crap together that might work initially but after that person
leaves and another has to maintain the application, it is revealed that it
makes no sense how the ball of mess keeps working. At that point, management couldn't bribe a good developer to maintain it –
and management has to pay for the software to be rewritten. What a
waste. This happens all too often,
though. How many times have we been on a
rewrite project?
If you have a rewrite
a piece of software from scratch, take the time to learn from past mistakes.
If you’ve ever been on a rewrite project, you’ve heard
project managers belabor the faults of the previous edition and claim that
“we’re going to do it right this time”.
What fails to happen is a critical retrospection of the method of
development of the initial package and what possibly caused the software to go
to hell? This step doesn’t happen, and
the rewrite occurs using the same methods.
To then expect a different result would be insanity.
It’s too easy.
It’s too easy for an unskilled person to throw a screen
together and deploy it. It’s too easy
for Joe blow to create a database application that pulls over entire tables to
the client for modifying one record (but it works – initially). It’s too easy for a newbie to get excited
about a new technology and completely screw up an application with web service calls to itself and overdo sending XML to Sql
Server 2000. It’s too easy for a database
guy to throw tons of business logic in stored procedures, call them from ASP
and call it an application (until a skilled programmer looks at it later and
has a heart attack).
If software is to be
easy, then it must also be disposable.
That’s right. If an
unskilled person throws together a piece of crap that is then used for a while
by a business, the management must know that if they need to change it and the
original author isn’t there, he’ll have to pay for a total rewrite. Like in the car insurance business, if the
cost to repair a vehicle is greater than the cost to replace, then the car is
totaled.
Apprentice,
Journeyman, Master
These are time-tested levels of skill in many
disciplines. An apprentice is not
trusted to work alone because the apprentice is unskilled. The apprentice could have the best of
intentions and know exactly what the customer wants, but he’ll make a mess of
things if left to work alone. Not all
apprentices make it to Journeyman (where they are trusted to produce good
work), and not all Journeymen make it to Master (where they are given the
responsibility of ensuring quality and training the others).
I’m not the only one
who thinks software is too easy: