Part of the issue is that programming systems are defined by the user’s needs, which are infinitely varied across companies. Once you step out of standard software packages and into the custom code world, every system is completely unique and is shaped by the users and by the individual humans working on the project.
This is one of the joys of working in software in my experience, since even problems that are similar to ones you’ve solved before can add new twists and features, keeping the work fresh and challenging.
At the same time though, this is what prevents me from referring to software development as engineering, because there is no silver bullet, no common standard or schema for doing things.
We are artists that are really good at math and logic.
Look at the estimation problems we have in software. How many of you out there can truly, honestly, to the day pick out when you will be finished with a software project?
The bigger the project, the rarer this ability is. Sure you can fudge your numbers and add padding so you can be reasonably sure you won’t be late, but calling your complete date agressively is near impossible in large projects with many team members simply because you are working with thought-stuff and unlike building a bridge, you can’t pull a template from the last 40 bridges you’ve built and nail down a relative time line.
Additionally, the human factor kicks in on large projects. It has been well noted by researchers like Sackman, Grant, and Erikson that “very good professional programmers are 10 times as productive as poor ones”.
This is also unlike building a building where the variance in productivity between say, people putting up drywall is far less than 10 times. If software development was more like engineering you’d be able to walk in and say “oh, you want an invoice billing system, that’ll take 500 hours” and you’d hit that target nearly every time. This is far from reality.
Rejecting Software Engineering - Eric Wise
Tags: 10xSoftware Engineering, Software Engineering as an art
