Sunday, February 8, 2009

No Hands for Beginners

In most large government contracts, the vendor specifies a target technology, at the moment in Australia this seems to be split pretty evenly between J2EE and .NET. Clearly there are considerations that need to be made when choosing what language, etc to use such as operating environment (if the client has a general Oracle licence, offering a SQL Server solution is a little silly). Beyond this, what the hell are clients doing choosing technology stacks? Let's have a look at a few of the normal excuses.

"X is a well-established technology, so it's lower risk than Y"
Aside from the fact that government vendors accept pretty much zero responsibility in large projects, in my sadly ever growing experience large government contracts can fail for a variety of reasons. Poor communication, people in over their head, in-fighting on either side, stubbornness and power-tripping are all excellent candidates. I am yet to see anything fail because a class had import statements instead of include statements.

"We won't be able to find anybody to support that"
One of the most pervasive myths of development is that the programming languages somebody knows is important. Maybe it was important at the dawn off programming, I don't know, I''m not that old. Any modern OO language can probably be picked up in a few weeks by a decent developer who knows at least one language. It might take a bit longer but it will definitely be less time than it takes to get to grips with a vast code base of uncommented, hastily written code in a language that wasn't really a good fit for the requirements.

"I read an article on the internet that said..."
I would like to respond to this particular argument in two ways, first: shut the hell up. I will find you an article that says the exact opposite if you give me five seconds. Second: there's a person on the project, probably with a role like system architect or similar whose sole job is to make these kinds of decisions. Failing that, maybe the people who spend forty hours a week or more writing code have slightly more informed opinions on such matters.

I guess what it boils down to is that if you don't know what you're talking about, take your hands off and trust the people who do to make the right choices.

2 comments:

jml said...

As you well know, I very much agree with the principle. However, I wish to quibble about the language point.

Most decent programmers can pick up new languages pretty quickly, and then use these languages to make something that mostly works. However, many languages and language implementation have subtleties that are necessary to understand in order to build a high-quality system.

For example, to build a fast system in Python, you need to know a lot about how CPython works. To write a decent XML-RPC application, you need to know about xmlrpclib's brokenness wrt Unicode.

For another example, to build a system in C++ that doesn't leak memory, you need to know about the interaction between destructors, assignment operators and copy constructors.

None of this makes maintenance impossible, but it does make it more expensive.

Bice Dibley said...

That's a fair point (although I wouldn't count C++ as a modern OO language).

I guess it depends a lot on the nature of the maintenance as well. Subtle, systemic problems definitely require deep language knowledge, but the much more common missing input validation, null pointers, etc can be fixed by basically anyone.

The most common situation, of course, is that the company that wrote the code does the maintenance at which point expertise should hopefully not be an issue.