Object Mentor Blog: The Things That Pass For Simple I Can't Understand

The Things That Pass For Simple I Can't Understand

tottinger — Thu, 14 Jun 2007 00:19:00 -0500

(with apologies to Steely Dan for the nearly-lyrical title)

I’ve noticed that “Do the simplest thing that might possibly work” gets universal agreement in principle, and great divergence in practice.

Is a set of variables related by name prefix simpler than a named class containing the same variables? In the “fewest number of the fewest things” sense, I see a group of variables as a lot more to manage than a class. I can’t understand why some people pass the same group of loose variables to a number of methods. Isn’t a seven-argument method “complex”?

Is a custom exception “fancy” or “trivial”? I’ve had that discussion recently. Some feel one way, some the other. Is it more complex to throw a standard exception type and then try to figure out what it means elsewhere?

Is event-handling simpler than polling? I’ve heard this one too. I don’t know how other people see it. I think events have more complex plumbing, but that polling has a greater run-time complexity because of failure modes (periodicity issues, race conditions, etc). I think that it is simpler if you have fewer problems to look out for.

If you need a fixed set of java instances, is an enum simple or fancy? Here you have a newer language feature, but it exists to simplify the management of a fixed set of instances, so it leaves you less to deal with, no?

Is “more primitive” simpler? How about if you use arrays and integer indices into a string rather than a list of strings? Is that simpler or more complex? Is the Bowling Game “simple” because it uses a primitive array and a separate array counter instead of custom objects?

In C++, is it simpler to have a struct that contains two data members or to use the pair<> template? Is it “simpler” that you have to refer to them as “first” an “second”? Or is that just more obscure? I think that “obvious” is more simple.

I am not sure how other people judge simple. I think “simple to use”, “less bookkeepping”, “harder to mess up”, “less setup to call”, “fewer parameters” are simpler. Other people seem to have contrary thoughts.

Clearly simple involves more than “least thought” or “most primitive data components”. It should have something to do with the lack of effort in using something and the ease with which things can be used correctly. Well, clearly to me. And it should have to do with the least difficulty in reading the resulting code, and the least difficulty in changing it.

Unrelated to this, I find some tools that others find simple to be baffling, and some tools that are complex to others seem pretty easy to use to me. I suppose that’s a kind of “personal taste” but is there a more reliable rule to base “simple” on than personal choice? There should be if the rule is for us all to do the simplest thing that works, and to maintain the simplest design we can afford to build.

But I have unique viewpoints sometimes, and maybe simple to you isn’t simple to me. Personally, some of the things that are simple to you may be all but inscrutable to me. I guess that happens.

"The Things That Pass For Simple I Can't Understand" by creatine

Thu, 02 Feb 2012 07:10:52 -0600

Good informative content is written to target the thinking person. This content is brain-challenging yet straightforward. The viewpoints are written with a lot of thought and prep work behind them.

"The Things That Pass For Simple I Can't Understand" by bodybuilding

Thu, 02 Feb 2012 06:47:50 -0600

I have only one regret for landing on this article site. That regret is I can’t write really good content as well as this author.

"The Things That Pass For Simple I Can't Understand" by beats by dre store

Tue, 23 Aug 2011 03:29:17 -0500

understand the abstractions, you wind up totally lost. Design Patterns are high quality headphones new design headphones

"The Things That Pass For Simple I Can't Understand" by Christian louboutin shoes on sale

Fri, 10 Jun 2011 21:51:01 -0500

Women seeking probably the most excellent models inside the fashionable shoes or boots assortment uncover 2011 louboutin sandals available regarding exactly how pricey this kind with astounding designs are generally.

"The Things That Pass For Simple I Can't Understand" by beats by dr dre headphones

Wed, 08 Jun 2011 21:24:21 -0500

for people that adore music, i suggest the monster powerbeats sport headphones to you, Just Beats Studio Purple has three color, red, whit and black. It is significant efficacy on this monster diddybeats in-ear headphones.

"The Things That Pass For Simple I Can't Understand" by okey oyunu oyna

Mon, 25 Apr 2011 15:23:05 -0500

good article

Okey oynamak hiç bu kadar zevkli olmadi. Online ve 3 boyutlu okey oyunu oyna ve turnuvalara sende katil.

"The Things That Pass For Simple I Can't Understand" by Tenant Screening

Tue, 22 Feb 2011 10:54:24 -0600

I think maybe there is something akin to “exposed failure modes” as the inverse of “simplicity”. If Ican pass parameters out-of-order, accidentally pass one integer where I mean another, or mess up the handling of an array by setting an integer value incorrectly, make an object unusable by calling its methods out-of-established-order, or the like, then I’m not looking at something simple but something treacherous in its exposure of complexity.

"The Things That Pass For Simple I Can't Understand" by Criminal Records

Fri, 18 Feb 2011 11:43:50 -0600

Some say this only hides the complexity, but I would say that it literally reduces the complexity of the methods using the class (which are many) and adds complexity only to the class definition (of which there is one).

"The Things That Pass For Simple I Can't Understand" by shaded pold motor

Mon, 24 Jan 2011 01:39:51 -0600

This article is very usefull for me! I can see that you are putting a lots of efforts into your blog. I will keep watching in your blog, thanks.

"The Things That Pass For Simple I Can't Understand" by Tim

Tue, 06 Nov 2007 13:20:15 -0600

More on simplicity and complexity: http://betterexplained.com/articles/combining-simplicity-and-complexity/

"The Things That Pass For Simple I Can't Understand" by Tim

Wed, 08 Aug 2007 21:46:36 -0500

One suggestion is “Structural Simplicity” (thanks Mike). I think you are onto something here.

Okay, let’s look at the simplicity improvement if I create a class instead of having a set of loose variables. We can discuss an address class. Since I’m an American (and most of us are barely aware of how things work elsewhere), I’ll make it a US postal address. The address class has a street address, city, state, and zip code. The zip code has a funny relationship with city and state, in that only certain combinations are valid. The city has to be withing the state, and the zip code has to refer to that address combination (zip to city is many-to-many).

If I pass around the address as loose variables, the answer is more primitive but not simpler. Likewise if I place these all in a structure but pass it around in a writeable form, it is no simpler.

One problem is that there are a number of operations I can perform on strings that don’t make a lot of sense on addresses. Why do I want to substring them? “Worth” is a wholly different place than “Fort Worth”. There are a lot of operations I have available to me on a number of variables, and I have to know which ones make sense. This is a problem of too much variety. Each user of the structure will have to know which operations make sense on each member.

A second problem is invalid combinations. If I change the state, I will have to change the street address and likely the city. I will certainly have to change the zip code. There are many ways I can fail to have a valid combination. This is a problem of having too many exposed failure modes. Every client of this structure or set of variables will have to know how to validate them against each other.

The third problem is that I may be working more than one address at once, perhaps comparing them. I will have to maintain a clear separation in my head between the fields of the two, and which values are in which place. This is somewhat alleviated by the structure. The risk of accidental shuffling is increased by the number of variables I have at hand.

The fourth problem is that any act of copying to another structure, to a set of loose variables, to a file, to a document for network transfer, to a database or to any other source will have the same set of operations. By not managing an entity as a whole, I have duplication of structure and this a multiplication of maintenance points.

It is worse, by the way, if I were to make the zip code an integer. Does the zip + 4 overflow? Is the zip a five-digit or 9-digit zip (I need to know for formatting, and because some receivers may want only 5 digits). What does it mean to left shift, bitwise-or, add, multiply, or square a zip code? I have even more noise to sort through with an integer.

Loose variables may seem “simple” (having only one moving part each) but having loose variables for a single entity multiplies complexities. I can clearly see that many times a more primitive answer is not a simpler answer, and not even an easier answer. But still there is primitive obsession in much modern code.

If I put my loose variables into a class, I can restrict the set of operations one may choose to those that are meaningful for the class. I can add methods to the class to extend the meaning in a clear way. I can build operations at the class/instance level and refactor them together to avoid duplication. I can add decorators to give short-term features to the objects. I can make the object responsible for the validity of its own state. These are things that you can do with a class (“not the simplest thing” some say) that you cannot do easily with more primitive forms.

These kinds of structural simplicity relieve the burden on the programmer (and each of the functions written) to have to know the valid states and operations of the cluster of data elements. Some say this only hides the complexity, but I would say that it literally reduces the complexity of the methods using the class (which are many) and adds complexity only to the class definition (of which there is one).

That sounds like reducing overall complexity. That sounds more structurally simple, and also results in things being easier to use and harder to misuse.

I said above:

A simple system would have very few moving parts, and very few exposed failure modes, very few degrees of freedom of movement, and the use of it would be more-or-less obvious to a biased observer

I think that this example helps to make the case. Fewer moving parts (one v. five) for users, less freedom of movement, fewer decisions to be made, and far fewer options to sort through in order to decide what to do next.

That’s simpler. Or structurally simpler. Or “more minimal” maybe.

And, finally, for my C++ friends, look at how I can completely demolish the real structural simplicity of my class by returning each of the variables as a non-const reference.

"The Things That Pass For Simple I Can't Understand" by TorbjÃ¶rn Kalin

Sat, 30 Jun 2007 16:26:05 -0500

I doubt there is one word to express all you want, especially one that for some people does not at the same time mean the completely opposite (such as “simple”, and also “clean”, I’m afraid).

Perhaps it would be easier to find a few values to describe your vision. “Simple” could be one of them, but perhaps not the one with highest priority due to its disambiguous tendency.

I would use “maintainable” since maintain the code is what you do most of the time, and “modifyable” as the design requirements tend to change.

“Understandable” is a good candidate (and perhaps it’s part of “maintainable”) but not a top priority. It often takes a few moments to understand OO code due to the abstractions, while functionally decomposed code is more straight forward. Yet I prefer OO code.

“Easy to use” and “hard to misuse” are two more good values.

Or define the values by giving counter-examples. “Easy to write” is clearly one of those: code will be read many more times than it is written.

"The Things That Pass For Simple I Can't Understand" by Tim

Fri, 29 Jun 2007 08:51:46 -0500

I think that the DTSTTMPW “simple” would have been better off named “easy” or “cheesy” or “dumbest”. I have respect for the word “simple” that isn’t deserved there.

I am really interested in “simple design” most of all. I admit that I should not have mentioned DTSTTMPW in this posting. I repent.

But I want a better definition of simple, and could be happy using a different word that means “simple” in this context. “Clean” starts to approach the right meaning, but is not precise enough.

Recommendations?

"The Things That Pass For Simple I Can't Understand" by TorbjÃ¶rn Kalin

Mon, 25 Jun 2007 02:51:32 -0500

I thought DTSTTMPW had to do with the make-your-test-work part of TDD. Here simplicity has nothing to do with values of good design. Instead, simple means as few keystrokes as possible or the shortest implementation time. Duplicate as much as you like. Magic numbers are king in the world of simplicity.

Then you put on you refactoring hat. Simple might be a good value to use here too, but it has a completely different meaning. And if that meaning is so hard to define, then is it really a good word to use? Perhaps it should be refactored into something clearer? :)

I share Tim’s experiences regarding problems with the definition of simple. In the name of simplicity, a collegue recently wanted to duplicate a class (copy/paste 500 LOC) instead of using strategy pattern. I agree with my collegue that his solution is indeed simpler in many ways (simple to write, simple to use, simple to understand), and would therefore use other design values (simple to maintain, simple to change/modify) to motivate the strategy solution.

"The Things That Pass For Simple I Can't Understand" by Grok2

Tue, 19 Jun 2007 10:59:05 -0500

At work, I end up maintaining a lot of code that other people have written…in the end, to me, simple code is something that is easily understood. And which usually is code that is written in the simplest way possible. But the interesting thing is that the simplest code is usually written by the more experienced programmers…less experienced programmers tend to be inconsistent and simplistic (as opposed to programming simple-y) in their programming!

"The Things That Pass For Simple I Can't Understand" by Tim

Tue, 19 Jun 2007 08:54:54 -0500

PJ: I agree. Having more collateral effort pushed into a client doesn’t decrease the complexity, it actually spreads it. If the function receives seven parameters and then manages them itself, it is in one place only. If, on the other hand, every caller must collect all the parameters into a structure or class before calling, then all of the callers have this collateral effort (caller-side complexity) to deal with. This is a fact dealing with cardinality: one function v. multiple callers. It is also clearly an issue of removing duplication.

But likewise there is the question of why we have seven parameters on a function. There are very few reasons for such a thing. One is primitive obsession, where (for instance) one may be passing coordinates for two objects as sets of loose integer variables instead of having a coordinates class. Another reason is that the function is doing several things and uses some of the variables to choose which of the others it should look at. It is also possible that the function is a constructor, and has a lot of dependencies (perhaps too many). At any rate, having seven parameters makes me suspect “not simple”. Likewise, having too many member variables or too many methods says “not simple”.

I remember Bjarne Stroustrup saying that in a well-designed system, the average number of parameters per function approaches one. I think that was in Champaign/Urbana, back in maybe the mid-to-late 90s. I think he’s right.

Given a choice, though, I do agree with you that complexity belongs in the smallest number of places, and in this case it should be pushed into the function, not pushed out as duplicated work on all the callers.

Jan: it might have been you. It’s a good quote regardless. I like it alongside this one on project risk:

       required time
risk = ----------------
       allowed time

"The Things That Pass For Simple I Can't Understand" by PJ

Tue, 19 Jun 2007 08:21:40 -0500

> Isnâ€™t a seven-argument method â€œcomplexâ€?

Maybe. Sometimes simple-to-use means complex internally. For instance, one could read your arguments to mean that all parameters should be put in a struct first. That, however, may be more complex due to the overhead of having to create a struct if one doesn’t exist. If the seven arguments come from seven different objects, then the seven-argument-method is indeed the simplest one to use – anything else will involve the overhead of creating a struct from those seven values.

"The Things That Pass For Simple I Can't Understand" by Ivan Tikhonov

Tue, 19 Jun 2007 08:06:52 -0500

You should read Chuck Moore. He is a marginal guy. And his margin is a simplicity. He build his own processors because he does not like bloated hardware. For doing this he built his own OS, CAD, character set and keyboard.

OS is 2kb. CAD is 500 lines in his own language for sure. Charset is 86 characters, ~5.2 bits each. Keyboard has 27 keys.

Jef Fox has an article about Moore and his way: http://www.ultratechnology.com/forth.htm

Also his quotes: http://www.ultratechnology.com/moore4th.htm

"The Things That Pass For Simple I Can't Understand" by Jan Daniel Andersen

Tue, 19 Jun 2007 07:44:00 -0500

@Tim. Hehe.. you might have seen that equation on my email signature or perhaps you read my little blog entry (http://blog.10footego.net/blog/_archives/2007/1/26/2684503.html) about my perception of skill :). But then again, maybe you saw it somewhere else. I do feel a little honoured though :).

I understand what you’re aiming for and I can see why my comments above, doesn’t quite cut it.

"The Things That Pass For Simple I Can't Understand" by Tim

Mon, 18 Jun 2007 07:55:34 -0500

I don’t deny at all the value of “understandable”. I appreciate that. I think that’s “simple v. hard-to-understand” and am in favor of it.

I am currently interested (for different, related reasons) in “simple v. complex” though. I concede that the DTSTTMPW was really meaning “easiest to envsion right now”.

I also disagree with patterns being “simple”. Flyweight and visitor and several of the others strike me as being non-simple solutions, but reusable in their context nonetheless. I think that visitor in particular, though quite useful, is complicated in number of interactions and complexity of interactions.

Yes, yes, a complex system can work too. I am not saying that complexity can’t work. My goal is not to eliminate anything complex, but to work toward a definition of “reasonably complex” v. “unreasonably complex”. As with big O notation, the purpose is more to observe the difference between the required complexity and the actual complexity of the solution.

I recently read (I don’t recall where) that the skill of the developer is:

           complexity of problem
  skill  = ----------------------
           complexity of solution

This is a good axiom, a nice observation. But it spurred me to think about things not just seeming simpler (a darned good goal all by itself) but being simpler in fact. I am now trying to find a way to measure simplicity.

I of course know about McCabe’s cyclomatic complexity (and I believe it’s right, also). But in an object system there should be something similar.

I think that “seeming” simple is relative, but that there should be an “actual simplicity” that is measurable and concrete.

"The Things That Pass For Simple I Can't Understand" by Jan Daniel Andersen

Mon, 18 Jun 2007 04:42:17 -0500

@Mark Wilden. You are right about “most understandable” being the â€œleast common denominator.â€ But this will only be a problem if you have too much spread in skill within your team, and I would argue that, that is a bad thing.

If you HAVE TO have a few team members with skills way lower than the rest, you need a time budget, to bring these up to speed, and this will ofcourse affect the progress.

@Tim Ottinger. I think understanding is key to all the things you mention. I see no reason to keep things simple if it’s not from an “understanding” point of view. It’s not hard to make a complex system work just as well as a simple system, unless the complexity defies our understanding of it. In essence, the final system, “doesn’t care” whether it is simple or complex. Only when we need to look at it again and need to understand it’s inner workings, do we see the difference.

I think that simple is a relative word, and can only be made concrete in it’s meaning among people with a common base.

BTW: I like your philosophical approach to these thing :-).

"The Things That Pass For Simple I Can't Understand" by Ben Rady

Sun, 17 Jun 2007 22:56:58 -0500

Doesn’t “simple” depend on shared experience? What’s simple to me could be unendingly complex to someone else (for example, a non-programmer).

One way this manifests itself is through abstractions. Abstractions often make things much simpler, but if you don’t understand the abstractions, you wind up totally lost. Design Patterns are a great example of this (Oh, it’s just a Flyweight!...What’s a flyweight?)

Another way would be the shared understanding of members on a team. While the team can often (but not always) come to an agreement about solution A being simpler than solution B, if you leave the friendly confines of the team, you often (but not always) start playing by a different set of rules.

"The Things That Pass For Simple I Can't Understand" by Tim Ottinger

Fri, 15 Jun 2007 10:42:19 -0500

There’s rather a great deal of difference between being a simple thing to imagine (cheesiest) and being simple. I respect the value of doing something so that you splash come code on the page, but then once it works it needs to have simple design.

If I scribbled up the first thing that crossed my mind and didn’t ever go through the effort of making it simple (expressive, clear, obvious, uncomplicated, etc) then my code base would go south in a big way.

So I’m okay with doing brute-force kinds of things like “return true” when TDD-ing, but then there is some standard of “simple” that interests me as a target for my refactoring.

YAGNI and OAOO and Tell-Dont-Ask are techniques for approaching “simple”, and I love that. I just wonder if there is some way to say what simple is, rather than just “what comes from YAGNI, OAOO, TDA, and tasteful use of explanatory functions and variables”. What is it really?

I think it has something to do with least-collateral-effort-to-use, and fewest-inobvious-failure-modes, fewest-parts, simplest-parts, structure-shy-interactions, etc.

So I totally respect what John says, and I still want something entirely other.

"The Things That Pass For Simple I Can't Understand" by Andrew Macdonald

Fri, 15 Jun 2007 08:49:03 -0500

Simple is a personal choice

Itâ€™s interesting that one of the things that most developers try to strive is simplicity, especially when the essence of simplicity is such a personal sentiment…

http://www.cwk-technologies.co.uk/blog/2007/06/15/Simple+Is+A+Personal+Choice.aspx

"The Things That Pass For Simple I Can't Understand" by www.EdmundKirwan.com

Fri, 15 Jun 2007 05:57:34 -0500

Simplicity is complicated.