Puzzle - Who is Knight and Who is Knave

This is a puzzle that i read in internet sometime last week and thought of sharing it here.

There is an island that has people who always speak truth (knight) or people who always lie (knaves). Unfortunately, you need find the way to the capital of the island. You are standing at the fork and there are two roads - left and right. There are three people, let us call them A, B and C, who are native of the island standing near the fork. You approach them, they tell you the following statements

Two of us are knaves, one of us is knight and the road in the left goes to the capital.

Will you be able to find which road goes to the capital - is it left or right? 

Simplification and Generalization in Problem Solving

You scatter toy towers of varying heights on the floor and ask some five old kid to arrange the towers in increasing order of heights. Most likely, he is going to knock of the puzzle. His first problem (and yours) will be understanding the problem - what needs to be done. Once he understands, he will complete the puzzles with your help here and there.After sometime, you ask him to sort toy circles in increasing order to circumference. Most likely he is going to finish off this taking lesser time than his previous. 

Both the instances are specialization of sorting - a basic algorithm that is known to human being. Human beings were sorting objects in life much before sorting algorithms were put forth. All those sorting were merely specializations and they work in specific scenarios but not all. Rather than saying it won't for all scenarios it is better to say that it was not tried having "all scenarios" in mind.

It is when we think about "all scenarios" we forget the specifics and the properties that is unique to the given problem and start to think about the "commonalities". When we think about "commonalities" we abstract ideas/concepts and bring many levels of abstraction based on the "commonalities". The specifics that are known at the time of abstraction forms as a boundary condition for abstraction. So, it is also very important to think widely about a specialization so as to make the abstraction more flexible & accommodative. Moving from specialization to a broader generalization is possible only when we simplify the problem domain and think about "many scenarios".

In order to understand the problem, you have to travel towards specialization and in order to solve it after understanding it requires simplification and generalization (and for achieving this you have travel further in time, by time i mean experience).

In next post, we will see some of the ideas on generalization from neuroscience's point of view.

Software Design Puzzle #7.2 - Thread Pools & Tasks

Please refer to previous two posts on the same problem - Implementing Thread Pools and Tasks. Here is the link for your convenience.

• Software Design Puzzle #7 - Thread Pools & Tasks
• Software Design Puzzle #7.1 - Thread Pools & Tasks

Yesterday, i added a requirement that i want to have a priority for tasks (a problem on data structures and algorithms). Today, i thought about another feature that gives a lot of flexibility (real OO design). In the above examples, we didn't talk much about the threads in thread pools. Can we try to make threads in thread pool dynamic entity - based on the need, the number of threads in thread pool should grow or shrink. Here are my next set of questions.

1. What are the design decisions that i should take so as to make thread pool dynamic.
2. How can i make threads, tasks, thread pool at the topmost level of abstraction and yet get many different concrete implementations.
3. How can i ensure that the code I am going to develop after two years (due to new requirements) doesn't affect my code now (seal the code from modification for new requirements)
4. How can i bring in hierarchy, levels of abstraction and modularity for better design?
5. Do i have any design patterns?

Software Design Puzzle #7.1 - Thread Pools & Tasks

Refer to the previous post, Software Design Puzzle #7 - Thread Pools & Tasks. This post is an addendum to the previous post.

I m going to add one more enhancement to the thread pool design. The enhancement is to come up with a priority queue for tasks. Each task will have certain priority, an integer that increases as priority increases. At any given time, the task with highest priority has to be selected and run by threads in thread pool.

Can you refactor your design?

Software Design Puzzle #7 - Thread Pools & Tasks

We know what is thread. The thread is an independent execution path or entity in a process. When you want to exploit multi-core (increased processing) or do some blocking operations, the thread is the default destination (increased interactivity, heavy input/output operations). In any programming language that supports multi-threading, you run the code that can be run as independent execution path as thread with each having its own context. The infrastructure that is needed to run threads in parallel like stack, program counter, registers are tightly coupled with the code that runs. Due to this tight coupling, each time you need an independent path (let us call it as task), you create a thread (the infrastructure) which has its own overheads. Is it possible to change code of the thread?

Obviously the next step is to separate out the infrastructure and the task which is achieved using thread pools. Here is the next problem.

Write a simple thread pool in Java with following requirements

1. Have a fixed but configurable number of threads in thread pool. At any point of time, you can run up to N threads.
2. Have a task queue (or a suitable data structure). This can be much bigger than number of threads. The tasks wait in the queue for their turn.
3. The thread should consume tasks from the task queue and execute it. It can be any task (but you have to ensure some fairness). The role of the thread is to run task without bothering too much on what it does and how it does.

Puzzle - Help the Painter

Your friend is a painter and he paints houses for quite sometime. He is highly professional and highly sought after as he known for his quality work and fair painting charges. Throughout his life he has painted lot of houses that are regular sizes - rectangles, squares and circles. He charges his customer based on the area he paints. (you see calculating area for regular shapes is cake for him)

Last week, a new potential customer called him up for a huge order that will keep him and his team busy for next five to seven months. The catch here is that the customer is not willing to pay a penny more and even your friend being a professional painter wants to quote a fair pricing strategy to his new potential customer to win this order. BTW, did i tell you that the area to be painted are irregular shapes.

The painting area is

• Irregularly shaped like amoeba
• Each surface is uniquely shaped (bare minimum he needs to paint 1000 such surface different in 1000 ways)

What is the pricing strategy that your friend can offer to his customer so that both your friend and his customer is happy.

Organizational Entropy

Entropy (thermodynamics) is the energy that is not available for any useful work. Entropy in software measures the degree to which it is unordered, degree to which it can't be maintained. Entropy in organization measures the degree to which the workforce is unfocused & unordered. Though the field of application is different, by the very definition we understand that entropy is not a thing to boast about. The system continue to go in favor of entropy unless it is taken out in the form of heat.

Entropy in organization implies that energy that is available and that will eventually be spent on matters that is not so useful to the organization either be it taking too much of tea for a prolonged period in cafe or putting up a strategy in a conference with tea (or beer). All these are efforts which won't necessarily be converted to results. The next question that may come you mind - "is entropy same as that of being unproductive?".

Being unproductive is the result of having an entropy at higher side. Productivity is a metric that is measured after the event has happened. You have to wait for a week, a month, a year or until you have next meeting. But entropy measures how much of energy you have and what portion of it will be spent on things that will have little to no impact.

I feel like measure on entropy, and trying to reduce it, is a proactive approach than doing with measuring productivity alone. You better remove entropy periodically. Keeping a check on entropy increases the awareness and anticipation which in turn increases the probability of producing productive work/results.

Either in software or organizations, the entropy has to be worked against.

Related Links

Entropy in Thermodynamics

Entropy in Software