Sunday, May 08, 2005

Software development: Art or Science?

I'm going to try and set the foundation for future discussions here by thinking about some issues that I think are really holding IT back from advancement. Metrics, developer evaluation, management, development techniques, and outsourcing are all subjects to come. Right now I want to discuss something that's bothered me for a long time.

Do we know what the heck software is?

Of course, you say, we do, it's that collection of zeroes and ones that power an entire industry in the technology field. But with regard to development, why is it we keep shooting ourselves in the foot in IT projects? The answers can come from a dozen different places. Management is always a major factor, but so is the lack of metrics in our industry, and that the technology is still relatively new. That it's always changing doesn't help.

One of the problems is I think a misconception about it. Software and hardware both come from the discipline of computer science. Well, that word, science, implies reliable predictability. If you're a developer of any experience, you know that users, software, languages, hardware, and business requirements are neither reliable nor predictable.

Thus the struggle I have with the question, "Is software development an art or a science?"

It's a science because we've seen how the hardware we run on depends on the laws of physics and we're beholden to those laws. When we code, we know our code follows certain logical pathways and we know that features and abilities in our languages will uphold (most of the time) repeatable results, and that we can usually identify a change and its effects on our code. That sounds pretty scientific.

But it's an art too, isn't it? We start with a blank screen and with work, we end with a page of script or code that can do some amazing things. Software developers don't just crunch numbers, they also design graphic user interfaces that communicate with humans, digital interfaces to communicate with other machines and operating systems, and are continually striving to modify the code for processing efficiencies. Those things all require some creativity. Designing database schemas with efficient and maintainable structure, that's a task involving both science and art. Designing a software framework that can reduce maintenance hassles down the road, that takes real ability to plan and to process and research past experiences. It's not just about hammering out a couple IF statements. And when you look at it that way, it can sound pretty artistic.

And I think that's one of the problems in IT. Nobody really understands software. HR people, managers, and executives think IT is just a cost center that wastes money on that thing called applications development. It can't be that hard, nice software like Quicken only costs $30 after rebates, right? NO! Not right. Slapping out some code is easy, but making it sing is hard. Making it sing in tune is even harder. Making it sing in tune, in a choir with other apps like Oracle Applications, SAP, and Windows, across an unreliable phone line to a remote isn't easy, and some of those expensive choir members don't sing too well themselves!

But people at the top are often too quick to assume that computing technology is all simple science. Few realize that it's much more variable and complex and contains unpredictable artistic elements. That is, I suspect, one of the leading causes of misguided project plans and therefore a cause of having to burn the candle at both ends.

Here's another problem: managers and executives aren't the only ones that misunderstand the complexity of software. You know who else doesn't get it? Software developers! Yes, that's right. In my short 15 years in this industry I've figured out that most of us are complete morons. Mediocrity is threatening the quality of applications companies use, and that's debatably just as damaging to this industry as any mediocre manager. When I was contracting, I couldn't believe how many of the contractors were complete idiots. They could put together some basic things, but good grief, when an entire population of them didn't understand or care about database theory and didn't strive to perfect their craft by studying advanced techniques, it just doesn't speak well of us as a whole. There were and are guys I've crossed paths with that completely dismiss the artistic side of the development equation. And of couse those guys are getting paid more than me to work half as much, but that's a discussion for another day.

Anyone can figure out the IF statement. But it takes a real professional, one who equally reveres the scientific and artistic sides of our business, to truly earn the title of software developer. That means doing the artistic parts that aren't so fun: interacting with users to find out what they really want, learning the business, striving for code perfection in both function and form, DOCUMENTING their work for both other developers and the user community, and remembering always to never stop learning.

No comments: