Reasons (Some) Developers Like Complexity
There seem to be several reasons that developers (including me at times) have created unnecessarily complex code. These include factors discussed in the two just-referenced blog posts. Here is a quick list of some of the prime reasons some developers (maybe all of us at one time or another) seem to generate overly complicated code.
- Lack of understanding of problem - Code can be more complicated than it should be because the problem is not well understood. I almost always realize after I have completed a piece of code that there are ways I could make it simpler or refactor it. This is often a result of better understanding the problem after working through it.
- Lack of understanding of technologies - Code can sometimes be more complicated than it needs to be because the developer doesn't realize there is an easier way to apply the same or even an alternative technology to the problem. For example, I have seen (and heard of) projects where developers essentially wrote their own web servers, data stores, and application servers. On a smaller level, it is easy to write complicated code that could be greatly simplified by using established libraries and frameworks.
- Job Security - I don't think this is as common as some allege, but there is no question that it does happen. If a developer writes code that only he or she can understand, the thinking goes, he or she will become indispensable. I personally find this a little short-sighted and think it typically will only work for short-term security, but that doesn't mean some people don't believe it works for them.
- Show Off - Ever since Elementary School show-and-tell, many of us have had a desire to show off. This can definitely be a factor in why some code is more complicated than it should be, but it can also be difficult to differentiate this motivation from the next two listed here.
- Guilty Pleasures - It is sometimes tempting to write complex code just to see if we can. I have classified this as one of the software developer's guilty pleasures. After showing ourselves that we can do it, we might look forward to showing it off to others as well (the previous point)
- Hell is Paved with Good Intentions - We sometimes bring the complexity upon ourselves by trying too hard. I think of my own early overuse of implementation inheritance when I first learned about object-oriented programming and my similar overuse/abuse of design patterns when I first started looking into them seriously. Unfortunately, it seems that many of us have a tendency to think if a little is good, a lot is great. We are prone to focusing too much on one -ility (especially flexibility) at the cost of other positive features (cannot see the forest for the trees).
- We Cannot Help Ourselves - Unnecessary complexity is not limited to software developers. One simply needs to look at the United States tax code, at most software licenses, at most warranties, or at many other everyday documents to see how prevalent complexity has become in our daily lives.
(Some) DBAs Love Complexity Too
I enjoyed the previously cited blog posts on developers and complexity because I have seen the things they describe. I have also seen that (some) DBAs seem to love complexity as much as (some) developers. Here are some anecdotal examples.
- Whereas some developers do seem to love overly complex object hierarchies, I've seen data models that are so complex that they could rival any class diagram in terms of size and complexity.
- Whereas some developers do seem to love write complex code that is difficult to understand, the most complicated piece of code I can recall ever seeing was a crazy SQL statement with numerous joins and unions. The only person I knew that could understand it was the DBA that wrote it. Even the other DBAs wanted nothing to do with it.
- It is very easy for we developers to get so enamored with design patterns, best practices, and other rules of thumb that we overly complicate what should have been simple. DBAs seem to have a similar tendency to get carried away in their own chasing of patterns and best practices. I have seen cases where extreme database normalization has led to data models that are difficult to maintain and slow to perform. Database Design ROI discusses some of the costs of overly complex and difficult database design.
It seems like the software development industry (including database administration) is full of unnecessary complexity. This may be for several reasons as discussed above. Because the reasons are so diverse and so cover so many different types of people, I don't see this going away anytime soon.
RMOUG Training Days 2009
Speaking of database administrators and developers, RMOUG Training Days 2009 is just a little over a week away. This conference is an excellent source of information and networking for both developers and administrators. Because I tend to focus on developer-oriented things, this conference is a nice opportunity to see some things from more of a database administrator perspective.
Ann Horton has put together a blog focused on Training Days 2009. This blog already includes several entries including postings on OTN representatives at Training Days (with OTN Greatest Hits 2008 DVDs), why one should attend Training Days, inviting managers and supervisors to Wednesday afternoon events, logistics such as Littleton Light Rail availability and directions and parking, and more.