Last night at dinner the question came up: Why do software engineers always complicate things??? There are two sides to the coin, good intentions, and poor intentions. I think most people end up complicating things because of good intentions. The poor intentions are worth being aware of too, but I don’t expect the worst in others. In any case, overly complicated software indicates wasted effort and a problem for the business.
The good intentions:
Desire to use the latest technology:
Every good software professional loves to learn. It is part of their DNA. The software profession forces people to learn in order to stay relevant because every 3 years a new cycle starts.
Most people do not want to eat the same bland oatmeal everyday. Adding a few raisins is healthy. This can get way out of hand if left unmanaged. Imagine a team of software developers all hopped up on sugar – spinning in their chairs and climbing the walls.
Staying technologically current makes business sense, provided the technologies selected have a stable following and are of good quality. However, complexity is introduced if many new technologies are used at once, or new and old technologies are combined.
Software engineers, though they can be pessimistic in nature, rarely look closely at the downsides of using a new technology in your business.
Solution: Relate new technology back to the business first. Be careful of getting too fragmented.
Trying to do too good of a job:
Sometimes people get in over their head. Only wise confident professionals know when to admit it. Young engineers will over reach and senior engineers will incorrectly apply out dated approaches. Being perfect is not possible. In spite of how illogical it is, software professionals will spend a lot of time trying to perfect their work. They may introduce more bugs than they fix through this effort.
Solution: Figure out what is ‘good enough’ and go for that. This varies widely by industry and company.
Predicting the future:
Software professionals are very smart people. They try to anticipate what might happen down the road and build that into their design. In software, countless architectural features are created to solve problems that are not yet here and may never be.
Solution: Check with someone higher up to see if your grand architecture makes sense, or if it is just a lot of crap for QA to test through.
The bad intentions:
Fear of Criticism from Peers:
One approach to building software is to use every possible technique, design pattern, and tool to build a feature. Adding complexity is a way of showing off geek muscle. How could a peer possibly find fault in such a complete approach?? This is along the lines of the Second System Effect. (It is not like scoring touchdowns on home coming night were ever an option…)
Software Engineer A: Look everyone, my new feature can do X, Y, and Z!Business Owner: The customer only needs it to do X.
Software Engineer A: But Y, and Z are so cool because of {insert random geek sound bite}!
Software Engineer B: Wow, Y and Z, you rule! (thinks to self: I should add that into my project…)
Business Owner: *sigh*
Solution: Quality of the data model, code, tests, and documentation should not be sacrificed. Recommend the simple solution but present the complex solutions to prove you thought about it. Then see what makes more sense for the business. You might be surprised.
Job Security:
Insecure programmers will purposefully wall themselves off with bad code, undocumented systems, and tribal knowledge. Barnacles see complexity working in their favor.
Solution: Think twice before taking this route, your peers will smell the code, and your manager will be frustrated. Your job is to make your job obsolete so you can get on to the next challenge.
Lack of interest in the business and inability to communicate:
Some geeks are only interested in the technical aspects of their job. They care nothing for the business or the economic factors that justify their job’s existence.
Solution: Go out to lunch with a non-technical person. Get to know the business and those who really run it.
Contractor Mindset:
In contracting, if a task takes an extra day to complete, well the customer will just have to pay for that. That is considered ‘making money’.
Solution: Repeat business doesn’t go so well when people feel they got the short end of the stick. Reputation means more than a few billable hours. Work hard to manage expectations and let the customer know every time you save them money because you are so smart and dedicated to them.
Closing thoughts on the complexity issue:
The KISS principle is not taught in school!
K.I.S.S. = Keep It Simple Stupid
Does a short and sweet essay score higher than one with all the bells and whistles? – NO!
On a final exam, would a one sentence answer pass? – NO!
The education system encourages people to find the ‘right answer’ by knowing everything about the domain and then showing off their breadth of knowledge in a long winded report. That is great for research, and is necessary in many disciplines. However, we rarely have all the facts in business. As Collin Powell stated: once you know 80% of the information stop analyzing and go with a decision.
Conclusion:
Software is complex in nature, but it shouldn’t be for users. Sometimes it is honestly just a complex problem and there is nothing anybody can do about it.
Excellence in software, coding aside, involves understanding the business and unselfishly delivering results to further that end.
Quality is a continuous balancing act. It should be heavily influenced by the priorities of the business.