It’s always amusing to me when people find out I build software for a living and get this, “Well, that must be hard!” expression. The funny thing is that bulding software, fiddling with bits on a computer, isn’t terribly difficult. If I need to add 2 numbers, any language will do that, and even if I had to write in assembler, it wouldn’t be all that hard.
The hard part of building software is dealing with people, your users. Case in point: I’m building a new website for tracking user groups and other location-based types of things. Converting an address to a lat/long for mapping is fairly straightforward. I know what to expect from the webservice I call that does the geocoding. I know what to expect if my database goes down.
What I don’t know is what the user at the other end of the line is going to do. Will he ignore all of the fields and just hit submit? Will he enter a bunch of fake data? Will he enter a city/state that is different from the zip code he enters? Will he first type it in Word, and the paste it using IE which retains the smart quotes? Will he even be a he, or just an automated script someone wrote?
And that, my friends, is the hard part of software development. I have a book from 1995 called Practical C++ Programming written to a developer who has practically no experience in programming. Sure you have to start somewhere, and using that book things like arrays, pointers, I/O, etc, don’t seem that bad. But throw in a sprinkling of real users, and let chaos reign.
One of the things I like most about Test Driven Development is that when we get those edge cases, we do something about it. We write a test that seeks out the bug (or defect, depending on your school of thought). Once that’s written, showcasing the expected behavior, we fix it, and we guarantee that it stays fixed for as long as we run that test.
So, bring on the users. I’ll be ready with my tests and we’ll dance the dance of war (while we deliver value, and do the simplest thing that could possibly work!).
I agree … being a software developer these days has very little to do with one’s technical skills and more to do with one’s ability to cope with business logic and work with others.
Mastery of business language is also such a big must… after all if you meet with a client and start mentioning database rows, arrays, etc they’ll probably think you belong in a mental institution!
By the way, congratulations at becoming a new father. ;)
I agree with both of you and concur in James’ congratulatorisifications.
Cory, if you ever get a moment, drop me an email as I have a few questions for you. I am now a TDD nut and need some advice on something.