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:
- John
Reynolds - Joel
Spolsky - Michael
Feathers - David Gay (1/3 down the page)
- And a great threaded
discussion here
Thanks for the article and all the comments…I’m an entrepreneur learning about software development to build out my trading system. It’s very cool to read all your opinions…all valid…it is a craft…a very cool craft…
nice piece! I quoted you in a posting I just put up about a closely related matter that really bugs me… the idea that SOA, components, etc, mean that “real soon now” enterprise class business apps can be developed by relatively unskilled techs who just snap the legos together. See http://michaelatmo.blogspot.com/2006/05/software-bricklaying.html
–michael
Mike,
I have been at a place where the goal was throwaway because the need to get something out was so great. That was rare, though. I would not let myself write crap knowingly, so did my best to write good code even in that situation. The other code thrown together in haste quickly became a burden when it just needed to be modified a little but not completely replaced (4 weeks later).
I don’t believe it when a manger says: “don’t worry. We can clean it up/do it right/finish it later”. Later never comes, and 10 years down the road it’s still being used and is a maintainance nightmare.
You are right about me not making a distinction between a product and a solution. I don’t believe there is a difference regarding how it should be approached on the technical side. Whether software for external customers or internal, it’s still software that has users. Sure the business strategists will treat it differently, but it’s still software.
You make no distinction between a product and a solution. That completely turns down this post. If you are building a product, you better think ahead in the design phase so that future changes remain marginal in cost. If you are building a solution however, changes happen often, your boss wants you to hack this thing together as fast as you can, and you end up with crapoware/throwawayware anyway. This crapoware is because of the goal, not the person doing it or the tool.
Solid post, Jeffrey.
Bob Reselman proposes the software guild idea in his book “Coding Slave” (worth a read – I think its a free download now).
Software has become too “approachable”, so that the barrier to entry has been eliminated. This has made it much more difficult (and more necessary) to be able to differentiate between the levels of craftsmanship.
Because every non-programmer that looks at the value of programmers is looking at every one of us as an equal representative. They see the crap they are handed by someone that is “winging” it, and it completely devalues their opinion of developers as a whole.
Maybe we should be licensed, like pilots and doctors. Reselman’s idea was a sort of certification by your peers (he rails against vendor certifications, which are developed by vendors just to sell more books, classes, and promote their own tools).
You can look an programming like writing a book. A lot of people know how to write words, sentences and paragraphs and word processors make that even easier but that does not make all the people great authors. Programmers need to have the ability to create good software and tools that make that easier won’t make a bad programmer better, it will only allow them to create bad software faster.
I write software with passion and I totally disagree writing software is “too easy”.
There are virtually hundreds of commercial and open-source tools that have been written to aid software development in managed environment (Java & .NET). Why is that? Because this is very hard and time consuming to develop mid-large applications in managed environment. It will be even harder in the future.
It was a hard lesson for me to realise soon after .NET was released the Framework wasn’t all about glory and fun. I wouldn’t be able to know about every single class types in the Framework in my life time. Little I know less I can do in my software development projects therefore I have to do a lot of research (work) to do work.
Picture coding against 100+ SQL tables and writing all the classes by hand. I’ve been developing my own Tool (ORM) that generates over 200 classes for only 14 SQL Tables and still growing. Once you have the ability to make rich Business Objects then they way you look at the system design will be changed.
So I would agree that developing BAD or Less capable software is too easy.
Thanks, excellent post. I had similar sentiments in my blog.
With all the tools we have at our disposal now, software is indeed easier to make, but still difficult to make right.
The idea is conservation of resources (money, mental, or otherwise) at all times, and less about exactly when to conserve – that is the manager’s call.
Managers know the tradeoffs of time and money, typically very well. If they put you under impossible constraints they know what can happen. Their judgement call is what they get paid for, and ultimately how you were picked to be on their team.
OTOH you get paid for your ability, and that includes completing the job, or finding a new one.
Maybe the real problem is that it’s too easy to get a technical job?
Years ago, when I was entrenched as an RPG developer on the AS/400 platform (I’m now a Wintel geek), I read the Professional Programmer series of books by Henry Ledgard. He breaks down the levels of programmers, and sad to say, I’ve worked with too many amateurs.
Or should I say, have worked AFTER too many amateurs … as in “clean up afterwards”.
Sam,
Sorry about the link. It’s fixed now.
Bill,
I don’t have THE answer for that. There are probably many answers to that question. This isn’t a new problem, though. In general, it’s a management skill to be able to detect that a person for hire will be good at the responsibilities of the position. This requires a good manager (which is another topic).
Thanks for the flattery by calling me “Master”, but I don’t think I’ve made it to that level yet.
“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.”
jp: How is management to know? What criteria can be used to distinguish an apprentice/journeyman/master? How will management know that the person writing their custom software is unskilled, and the product will have to be discarded when change is required?
Teach me Master
if software is to easy, why are we (or you guys) having all these complicated conversations about how easy or how difficult it is?
sure is easy to trow something together and make it get the job done, but for anything a little bigger it requires talent, and talent is not something you learn
Yes no link love for us dude! -)
Are ‘Scott Bellware’ and ‘Sam Gentile’ supposed to be links? They are missing HREFs.
Good points, Eric,
Steve, yes. Writing bad software is easy, and writing good software is hard.
Writing BAD software is easy.
The problem you are speaking of is one that has already been solved by history, and you pointed it out. It’s the concept of a “guild”. Guilds police their own members, and handle their own rankings and promotions.
Guilds also solve the problem of a business manager “not knowing” about the skills of the developer in front of them by having a credible source to check against.
Just like in construction, carpentry, and electrician work the underpinnings of software are like the underpinnings of a building. How much more expensive is it to fix bad wiring once the building is up? The cheapest and most effective time to do good wiring is before the drywall is up.
However, that being said, not every application can be architected for excellence from the ground up. Start-up firms and businesses that simply don’t have the money to pay $200/hr at the time for a fancy master consultant often have to take shortcuts. Certainly they pay for it later but it would be just as great of a crime to allocate resources towards an enterprise architecture before the business needs it.
There is no clear answer for every situation, but I think most would agree that referential integrity is good for a database even if only one application ever touches it. The truth is that few databases have the luxury of only being used by one application, even if it’s just for reporting.
I’d consider foreign keys and valid range values to be reasonable database constraints.
If you are dogmatic that any data rules are business logic and need to be stripped from the database, then you couldn’t possibly choose database field sizes. You’d have to use “ntext” for all the fields because constraining a field to ONLY 8000 characters is a “business rule”.
Actually I want to ask you
I work in a project, and there was decision that the business logic should be in the business tier of the application and not in the database.
I agree with that, and there is no doubt about it that it is good practice
But what is considered business logic is the debate that I open sometimes
there is no validation on the database side (0 validation)
no foreign keys (except very few occasions), no valid range values
I argue that we have to put some validation in the database
but the senior architect consider those as business logic
and my question is where the business logic and where the validation border
another question, do you think database transactions, should be part of the business logic?
yes it is. Too easy to screw up, too easy to create crap, too easy to throw something together that’s a nightmare to maintain, etc.
Software is also too easy to screw up IMO.