The Architect´s Napkin

Software Architecture on the Back of a Napkin
posts - 69 , comments - 229 , trackbacks - 0

My Links



Post Categories

Who do you want to KISS? - About simplicity in coding

What does KISS really mean? How do you write KISS code like required by TDD for phase two when going from red to green? To answer that we need to know what simplicity is. Wikipedia says

“Simplicity is the state or quality of being simple. Something which is easy to understand or explain seems simple, in contrast to something complicated.”

Well, that helps, doesn’t it? No, I don’t think so. Because it begs the question: What is easy to understand?

I was wandering in the dark for a long time myself. Couldn’t really get a hold on simplicity. I had the feeling I knew what it meant - but then it still was hard to explain. But fortunately those days are over.

What one day cleared my understanding was a simple sentence I read on a page of B.J. Fogg:

“Simplicity is a function of your scarcest resource at that moment.”

Suddenly simplicity was easy to recognize and to apply.

But let me explain what my understanding of this definition is:

  • function of: Simplicity is related to something. Simplicity thus is relative. There is no absolute simplicity. Rather it’s in the eye of some beholder.
  • resource: Simplicity pertains to time, space, or any other resource. If something is simple more of a resource is left than if it was complicated.
  • scarcest: If more than one resource is involved in a matter then effort to create simplicity should focus on the most limited resource or the resource that’s hardest to replenish.
  • at that moment: Simplicity is not only relative in terms of resources but also in time. What is simple today might not be simple anymore tomorrow. And which resource to focus on today to relieve through simplicity might not be the resource to focus on tomorrow.

Now, is this a simple explanation of simplicity? :-)

Taking it seriously the answer has to be: It depends. It depends on the resource it tries to unburden.

What could possibly be resources involved here? How about:

  • Screen real estate
  • Memory on your computer
  • Memory on some server
  • Bandwidth
  • My time writing it
  • Your time reading it
  • Your time applying it

And what’s the scarcest resource in this list? The physical resources are plenty today. Those couple of KB are no burden on any of them. Which leaves us with time.

Is my time the scarcest resource? No. I’m willing to put it in. I’m writing pretty fast and it’s fun. No need to minimize its use - especially compared to your time or combined time of all readers. If I put in 2 hours instead of maybe 1 but thereby save each of a thousand readers just 1 minute in reading or applying the explanation… then that’s an hour well spend as a producer to save 16 hours on the consumer side.

So it’s about your time. But is this supposed to be a simple explanation with regard to your time reading it - or in the end applying it?

It seems a text like this should be succinct to save you time reading it. The average attention span on the web is short anyway. But I think that would be a misunderstanding. Striving for succinctness to make it a quick read is not targeting the really scarce resource. Your time right now might the short - nevertheless you’re investing it in reading. Reading, learning, that’s what you want to do in this moment.

Sure, the more you can suck in during that time the better. Your time for reading surely is limited. But what’s even more limited is your time designing a solution or writing code or setting up infrastructure. And it’s during that time you don’t want to get distracted by complicated definitions of simplicity. You need a simple definition to save your scarcest resource: production time.

If you have 1 hour to accomplish a task in a simple manner then it would be counterproductive to be force to lengthily ponder some definition of simplicity and how to apply it.

It’s certainly worthwhile to meditate over Leonardo da Vinci’s “Simplicity is the ultimate sophistication” - however I doubt this will lead you in a straightforward manner to a simple solution in your day to day work.

Or how about Bruce Lee’s “Simplicity is the key to brilliance”? Does that inform you whether to use recursion or not to achieve simplicity while coding a function? Again, I doubt it.

But what about B.J. Fogg’s “Simplicity is a function of your scarcest resource at that moment”? In my view that’s immensely helpful!

Think of the typical TDD situation. You just wrote a red test. Now you’re about to code a little to get it to green. You want to do the “absolutely simplest thing in the application code in order to get [the] test to run”. But how can you judge which approach to solve the problem posed by the test is the simplest one?

  1. Ask yourself, what the scarcest resource is. Examples:
  2. Do you want simplicity to save time during runtime?
  3. Do you want simplicity to save memory consumption during runtime?
  4. Do you want simplicity to save coding time now?
  5. Do you want simplicity to save reading time in the future when someone needs to understand the code?
  6. Do you want simplicity to save modification time in the future?
  7. Ask yourself which approach would save most of the identified scarcest resource.

I think the answer now is very easy: The scarcest resource right now during TDD is coding time. You need to get feedback quickly about whether you understand the problem and are capable at all to solve it. The simplest code then is the code you can come up with and type fastest.

But then, as we all know, code is more often read than written/changed. In the long run the scarcest resource therefore is reading or modification time.

As the explanation of simplicity made clear, the simplest code with regard to the coding time resource might not be the simplest code when looking at it from the perspective of another resource. What does that mean for the application of the KISS principle during TDD?

It means, you need to find time to optimize for reading/modification later. Interestingly TDD has this time built in. That’s what the refactoring phase is for. During refactoring you apply the KISS principle once more - now creating simplicity for reading/modification time. If thereby the simplicity for coding time is destroyed so be it.

As you can see: There is no such thing as absolute simplicity. You can’t create a simple solution once and for all. What is deemed simple depends on the scarce resource, which changes over the course of a day, across the lifecycle of a software, and varies for team members.

This final point is not to be neglected. Simplicity is not just relative with regard to resources but also depends on the beholder’s competency.

Even if two developers agree on the resource for which simplicity should be created they might disagree on which solution should be called simplest.

A recurring example for this in the .NET community is the use of lambda expressions. Some developers are very familiar with them and find their application to lead to simple solutions - regarding the coding as well as reading time resource. Other developers are not familiar with lambda expression and thus don’t use them at coding time, to keep their code simple. And they don’t like to be confronted with them at reading time; it takes them too long to analyze what’s going on in the code.

A simple solution for one person can be a complicated solution for another person. Sad, but true. The only way out of this is to keep all team members close together in their competencies (as long as there is a chance one member needs to deal with another’s simple solutions).

What does that mean for technologies like Linq, Angular.JS, functional languages, MongoDB, Pubnub etc. etc. which promise to make it easier to code simpler solutions? Well, simplicity has a price. It’s that simple ;-)

There are levels of simplicity that can be reached within a given technological horizon. But once you reach the top level you hit a glass ceiling. If you want more simplicity you need to invest into learning a new technology first.

So before you get lost in arguments whether a given solution is simple or not, first check if the discussion suffers from misunderstandings:

  • Is there a common understanding as to what the scarcest resource is for which simplicity should be created?
  • Are knowledge and capabilities of the participants in the discussion homogenous?

I guess in general you could say, solutions with less detail or more abstraction are simpler than solution with less abstraction or more details. But then… people not familiar with the abstraction may find more detailed solutions simpler.

This is also true for lines of code (LOC). In general solutions with less LOC might be deemed simpler. But then there is always a point where even less LOC make a solution harder to understand.

Sometimes that’s a matter of taste. But more often it seems to be a matter of experience with some technology or the problem domain.

So we’re back at simplicity is relative. But at least you now know what to look out for when trying to apply KISS. Be very clear about the scarcest resource. And once you have made up your mind try to minimize the burden on it.

It’s like a friendship kiss for a dear team member; an expression of sympathy, even empathy. Or if you don’t like to kiss men ;-) think of a manly man hug.



P.S. Just in case you’re still in doubt: In my view the chronically scarcest resource in software development is usage time. That includes the time users actually work with our software. But mainly I mean developers using code because they need to understand and modify it, plus developers using tools and applying processes.

It can hardly be overestimated how well invested an hour writing/setting up a solution is if that helps to make it simpler to use. This pertains to production code as well as screen designs and usability in general and infrastructure.

Simplicity focused on the scarcest resource is not a matter of beauty, but a matter of economics.

Print | posted on Wednesday, July 29, 2015 3:28 PM | Filed Under [ Software design ]



# re: Who do you want to KISS? - About simplicity in coding

I've always tried to live by a quote fro the great Brian Kernigan that I heard some time back -
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

So, I always make supportability a key factor in writing code - make it simple enough so that anyone (usually under stress when an issue comes up) can easily tell what the code does. Most code is WORM - write once, read many - so focus onmaking it simple to read.
7/30/2015 4:12 PM | Bob King

# re: Who do you want to KISS? - About simplicity in coding

Regarding the LoC statement, that's true for two solutions coded in the same programming language. However, does fewer LoC lead to cleaner, simpler code if a more expressive language is used? For example if code is migrated from Java to Scala. In my experience more expressive languages tend to make the code "simpler" (mainly in the sense of easier to read - following the WORM concept). But I would like to know, why we stick with these low expressive languages like C++/C#/Java while there are obviously (better?) alternatives. See also Is this really just a matter of knowledge and capabilities?
8/3/2015 9:33 AM | Andreas

# re: Who do you want to KISS? - About simplicity in coding

@Andreas: Surely languages and their frameworks differ in expressiveness. (But I doubt the cited analysis assesses expressiveness in a meaningful way.) So when I use language/fx VE (very expressive) I can devise as smaller solution to a problem than someone using language/fx LE (less expressive).

However, even though my solution is shorter and took less time to write than his, it is not simpler per se. Because simplicity for understanding depends on the reader's ability to, well, understand. If the LE-developer was to look at my VE-code he might not gain anything from it. It might take him much, much more time to understand and then change it compared to his more lengthy LE-code, just because he is not familiar with the VE language/fx.

But then, if he observes me several times being faster in producing and changing comparable solutions he might become motivated to learn the VE lang/fx. Then using VE will become simpler for him than using LE.

This is how our industry evolves, I guess. It evolves by contrast: Before we invest in learning something new we want to see evidence of it leading to simpler solutions. If the contrast between the current approach and the new one is stark enough then we might consider switching.
8/3/2015 12:38 PM | Ralf Westphal
Post A Comment

Powered by: