Big Data/Analytics Zone is brought to you in partnership with:

John Cook is an applied mathematician working in Houston, Texas. His career has been a blend of research, software development, consulting, and management. John is a DZone MVB and is not an employee of DZone and has posted 175 posts at DZone. You can read more from them at their website. View Full User Profile

Not Complex Enough

  • submit to reddit

One time a professor asked me about a problem and I suggested a simple solution. He shot down my idea because it wasn’t complex enough. He said my idea would work, but it wasn’t something he could write a paper about in a prestigious journal.

I imagine that sort of thing happens in the real world, though I can’t recall an example. On the contrary, I can think of examples where people were thrilled by trivial solutions such as a two-line Perl script or a pencil-and-paper calculation that eliminated the need for a program.

The difference is whether the goal is to solve a problem or to produce an impressive solution.

Published at DZone with permission of John Cook, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Andrei Dan replied on Thu, 2013/01/10 - 3:47am

Facepalm ! Headbang ! Jeeesus ! 

Simple is better ! Simple usually means easy to mantain, extend and scale.

Gordon Milne replied on Thu, 2013/01/10 - 8:02pm

For academics citations count most so, in some ways, an incorrect solution to a problem can be better than a correct one. In general, however, an impressive solution is what will get you a conference invite.

In industry (whatever that is), sales count and customers (mostly) do not care how things are implemented. So unless you work for the research arm of some company big enough to support pure research you do not get to spent your time think up the most impressive problem solving approach to fundamental problems like 2+2.

Alejandro Dobniewski replied on Mon, 2013/01/14 - 11:02am

 Sometimes you can solve a problem with a simple solution but you need to ask yourself: is this a duct-tape solution? need we a long term solution later?

I have solved problem cranking together 5 or 10 lines scripts. What happens when you need to add new use cases to the solution? is it documented? does it scale with the data? generate audit logs?

Not all duct tape solutions need to worry about that kind of questions but you can always think a little ahead.and solve not only today problem but also tomorrows.

After all, people that do so often are those who end as architects :-)

David Carboni replied on Wed, 2013/01/16 - 6:53am

Short and to the point. Pride kills good ideas. On a similar tack I find simplistic->complex->simple. To misquote Mark Twain: "I would have come up with a simpler solution, but I didn't have enough time".

Robert Brown replied on Wed, 2013/01/16 - 5:23pm

"The difference is whether the goal is to solve a problem or to produce an impressive solution."

Solving a problem often doesn't provide a solution.  I.E. I can solve a problem of running out of disk space by having someone log into the server every night and deleting a bunch of files, or even "Simpler" would be to buy a bigger drive.  That's a very "Simple" way to solve the problem.  However, it creates a bunch of other problems, staffing issues, access issues, security issues.  Or I can use a "Complex" system that has alerting and a management console to automatically maintain my disk space.  Which is "Better"?  Since the problem is disk space is running out the Solving THE Problem would imply hiring someone to log into the server.  However, the more complex solution IMHO is the Better solution because it reduces the risks as well.  And the "Best" solution, which would be changing the code that is running to not fill up the space is probably the most complex of all.  

I agree that the professor's comment of "I need a more complex solution to be impressive" is garbage, and I have seen plenty of code written to be tricky or take advantage of a quirk of a language, in the name of being "Simpler" but at the end of the day, IMHO the shortest Readable, Maintainable and Modifiable system is probably what wins out, but that is almost always not the "Simplest".  


David Carboni replied on Thu, 2013/01/17 - 7:13am in response to: Robert Brown

Interesting. I evaluate the "shortest Readable, Maintainable and Modifiable system" as the simplest. I'm most constrained on time to learn and rework code accurately, so that is my weighting.

Based on real-world experience with a multi-million hit per day website, I'll take human code over nerd-awesome almost every time (awesome has it's place, mainly in developing your own skills, but is only judiciously called for in practice).

If "running out of disk space" could be reframed as "service breakdown", security, staffing and people-time would become part of the decision. An automated solution becomes the simplest because even if it's complex on the "inside", it's less "costly" in terms of the relevant factors, so comes out on top.

Robert Brown replied on Thu, 2013/01/17 - 8:54am

Hi David, 

Right, the hardest thing for a good developer/architect/product manager to do is framing the Problem before coming up with a Solution, and convincing decision makers that the real problem includes all of the other things in the frame.  Many times people look at a problem using symptoms instead of in a more holistic way.  I.E. Symptom = DB Space Low, "Simple" fix increase DB Space.  Symptom program runs slowly, "Simple" fix increase CPU speed. 

Agile methodologies seem to promote this (they don't really but some people think they do) by saying only spec and design what can be done in a short period of time.  Which people think equates to not have an overarching architecture.  When you need to write a report, don't look to make/buy a report generator, write the report as a one off.  It's unfortunate when decision makers don't look at things in a systematic way, and instead concentrate on symptoms as being the problem.  

David Carboni replied on Thu, 2013/01/17 - 1:00pm in response to: Robert Brown

A good decision maker is a highly underrated skill.

By way of corollary to the "buy more kit" angle, here's an link worth reading:

Robert Brown replied on Fri, 2013/01/18 - 10:38am

Good article, and it makes sense to a point.  It only really works if the original design and architecture of the system is good.  I.E. if you build for scalability in the first place so that you can add a cheap server and have everything work.  Problem is that building for the scalability is something that has to be sold to the decision makers in the beginning, or it becomes much much harder to implement the more your system relies on quick and dirty solutions.  And most of the 

Note too for example that if you are running an Oracle server and need to add one more processor to it you are looking at at least 17,500 just for the licensing, and if you have built for scalability by using Oracle enterprise it's more like 47,500 plus the server cost.  Plus if you are using clustering its another 10,000.  Plus backup and monitoring costs etc. 

Also I've seen far too many times where throwing hardware at a problem winds up with a much bigger problem in the end.  For example say it's easy to get up and running by storing uploaded files in the filesystem instead of some more robust mechanism, then when the space starts running out rather than attempt to archive and find a software solution that is sustainable, more hardware is thrown at it.  Eventually you will wind up with a situation where the amount of data prevents you from even determining what is being stored (ever tried running a directory listing on a few hundred thousand files?).  Sometimes hardware can be a crutch that eventually cripples a system.  

Again it all comes down to being able to accurately and convincingly give decision makers the risk and reward of any system decision.  


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.