Multithreaded programming in layman's terms

Multithreading is a software concept that allows several programs run in parallel. While getting my head around it and talking to lots of folks about it I conveyed that we can compare multithreading with the real world.
Let's map concepts from the world of threading to the real world concepts.
OS is an enterprise. There're many different departments working at the same time. They can interact to each other in some way but it's not necessary.
Processes are rooms for the employees. Effectively rooms do not do anything. They are just compartments for the employees to work in.
Threads are employees. They are the ones doing any job we have whether it's designing a new marketing strategy or wiping out the streets.
Every enterprise can create rooms when it has a project to work on and assign employees to it. Usually you start with one thread per process and create more as you need.
Now, synchronization is a concept that can take a while to grasp. It is a way to allow different threads to interact with a shared resource.

Let's assume we have a single bathroom. If we were to allow multiple folks inside it would be hard to cope with the aftermath. So there can be only one person at a time. And that's what we achieve with synchronization. The simplest synchronization mechanism is mutual exclusion. Effectively it's closing the door from the inside once you're in. And nobody but you can unlock it.

Now there's another synchronization concept also described by Dijkstra called semaphore. It's a mutex with a counter assigned to it. Let's assume we have a bathroom with four standalone rooms. Once all the rooms are occupied the entry automatically gets locked out. Once there's a vacancy the door gets open again.

So far it's the simplest metaphor I came up wth. But it works while explaining it to newbies.

Why Lean

Why does it even matter?
Because we, as people building software, usually forget that the piece of software we're building is not the end goal. The profits, public awareness, social growth is. And the tool is not the driver of the business. You can cook delicious pastries in an ancient oven or in a high-end one. It's not going to make it better if you have screwed up with the recipe.
The recipe.
Figure out what is important. What are the most relevant flows for the customer. Which ones give you the highest conversion. Get metrics for the operation. How often do you need to click 10 times to get a report of one variable? How often does a human have to check tire pressure? What is the time waste? What is the effort to fix it? Count both in hours and dollars spent. Can we automate the process? Where does deficiency come from? Can we just remove the inefficiency? Can we make it semi-automated?
Improve if the ROI is high. Act on it! Do one thing at a time.
Validate what the result metrics are. Did you actually improve the process? Did you eliminate the waste? Does it work better now? Did customers appreciate the experience?
Apply the same approach to new products. Come up with the idea. Try it out. Make the implementation as simple as possible. Google search page still has only one input field and two buttons. But it's probably the most visited web site in the world. See if people buy into the idea. Get metrics around it. Groom it based on the metrics you have. Don't make the customer wait too long.
Measure what you do and what is the outcome of every feature you deliver. Save your time by not doing low-value frictions. Do high-value things. Now!

Does Java lack auto generated properties?

Is Java that bad in compliance to OOP pillars?

I had a few conversations with OOP developers in my community just recently and often it sounds like people want to have some new features as a part of the programming language they are using.

So we have auto properties as a part of C# 3.0, attribute accessors in Ruby and simple old getAttribute() methods in Java.

Now, we often expose internal state of the object to the outside world which I don't think is a good pattern for most cases. And as far as we're tired of writing those getMethods and setMethods all over we're trying to increase the productivity while writing those. Without consideration that most business actions affect a few properties at a time.

My take is we should expose methods that represent a business action like add two bags of potatoes to my shopping cart. The number of items, item type, SKU is integral for the action. 

So what if we change the process of adding an item to the shopping cart? For instance now we need to change the last update date of the shopping cart object every time we add something to it. If we were to encapsulate the change logic around the shopping cart object we would get a one line code change. Otherwise we are to change all the consumers of the object. Which I consider is a code duplication. Bad smell it is.

In this case I think languages such as Ruby and C# provide you both the toolset and the responsibility to make decisions on how to implement the solution. Java on the other hand gives you the only way to implement it property. But relies on the tools (all Java IDEs can generate property stubs) to make the development productive.