Scrum vs Kanban

From my own experience these days a lot of companies in UK associate Agile with Kanban practices a lot. Lets try to think though it. Agile methodologies emerged in attempt to manage uncertainty in a (not only software) project lifecycle. The essence of Agile Methodology is described by Deming Cycle:

• Plan
• Do
• Check
• Act
• Repeat

This process applies to projects, teams, iterations and pretty much every bit of interaction we have with a system called a software project. Any Agile ceremony should be tailored to add some value to one of the bullet points from the list above. Now, Scrum and Kanban are the Swiss army knives under the umbrella of Agile Methodologies. Both provide a toolset if you know how to use those properly. However, it depends heavily on a project and a Team which tool would fit better. In my understanding Scrum is optimizing the process for transparency and predictability when Kanban is optimized for bandwidth and resolving bottlenecks.

Scrum

• push culture (nurtures management)
• promotes transparency which imparts teams commitment
• pushing hard for predictability and constant improvement over iterations
• fits younger teams (less established) and provides sufficient guidance to avoid common pitfalls
• fits greenfield projects more when the amount of work is well defined and there's plenty of it

Kanban 

• pull culture (nurtures leadership)
• from my experience after pushing for some time and without being reminded of the uber goal people relax a bit. So we need some way of measuring where we're at with respect to the project as a whole
• operates from a prospective that the system's cost is as high as the cost of the slowest chain
• fits well established projects with senior teams more
• fits maintenance with non well-defined backlog when there're spikes of work

However, I don't think we need to prioritize one over another. Scrum suits perfectly fine when you're developing in a goal-centric environment. Kanban suits you much better when you're working in a one-by-one task environment (operations mode) and there's no clear end-goal. Just improvements along the assembly line.

Speed Reading

I always considered speed reading as a major way to improve one's overall performance. Especially in brain related activities.
So I read this book and here is a brief outline of it:

1. In a world that speeds up all the time reading faster without loosing meaningful information is vital.
2. There must be a goal (reading speed increase, ratio of speed to understanding) to aim and a time span to achieve it. 
3. Speed Reading Techniques:

• Reading the table of contents
• Meta-Guiding (pointing what to read next with you finger)
• Visualization (not a standalone technique still very helpful skill)
• Keyword search
• Chunk Reading
• Skimming (if you want to grasp the overall idea)
• Scanning (if you have an idea to scan for)

Gymnastics to widen up your sight area:

• Fixate your sight at a dot in the middle area of a text. Try to read from outer areas with your sight.
• Thumb-to-thumb glancing.
• Eye Writing
• Hooded Eyes
• Eye Squeezes

Exercises to increase your comprehension:

• Self-assessment
• Questionnaires, crossword puzzles
• Meta Cognition
• Extensive learning
• Communicate
• Contemplate

Other exercises:

• Push - up
• Push - down
• Alarm clock reading
• Timed reading
• 3-2-1 Drilled
• Chunks reding
• Speed Reading Comprehension tests

Additional considerations

1. Calming environment: light, noise ratio, smells
2. Focus: low level of distraction
3. Physical Exercise
4. Bad Food
5. Good Food
6. Sleep

Also discussed your tips to improve and fix major issues standing in your way and the overall benefits of speed reading.

I liked the book overall. It's a concise recap of good old technique with some more examples and ways to work it out.

Is AI a good or a bad thing

The history of the human race is a history of love and warfare.

A lot of things have been developed with no other application but fighting one alike.
We've got a whole lot of highly technological things such as nuclear submarines, jet carriers, interceptors, tanks and so on that can not really do anything but war.
Now, in regard to the most stunning examples of warfare I do want to give you some rough numbers on mortalities in the world wars:

World War I - 15,486,153 to 18,423,970

World War II - 70,000,000  to 85,000,000
It's not just numbers. It's all people. Someone's fathers, sons, mothers and daughters. Every single one was a person with his own history, aspirations and ideas. Lots of those people died not for themselves but for the countries, families and nations they were part of.

Now, with artificial intelligence coming to the scene I am considering a few major transformations of the world we know now:

• AI is to push a lot of people out of their professions. Today it sounds like only proles are at risk, but I'm quite confident that the next aim is white collars. IBM Watson can already diagnose patients better than the majority of MDs and considering more facts such as genomics. So in a medium term there's going to be a lot of people devastated by being pushed off from work they know without a plan to handle it. Consequences of this misfortune are not hard to imagine.
• AI is to set the bar high in the quality of care / farming / etc. But it will be very hard for people to catch up with all the knowledge computers can process on a factor of magnitude faster than any human being. And so lots of young professionals will simply give up on professions without even trying. The overall degradation of the educated people will commence across the globe.
• AI (at least the way it looks now) will learn from the examples provided by humans. Not only the results of the learning can be askew and we will get a nazzi AI but it will not really introduce any creative ways of doing things. And the society driven by AI will head towards promoting mediocracy. There will be no trial and failure loop or inventions made by failure. Tell me how many times great things started for you while thinking of something on a piece of napkin in a bar?

Now on the existential threat end

• If a passenger jet is hit by a missile, is it the fault of the missle or the one who launched it? Now, all the missiles of the world nuclear ones included are just a scratch on the surface what AI can become in a matter of days if not hours once it is born. Considering that AI learns so much faster than any of the best brains on the planet ever could will we be able to stop it if something goes wrong? 
• AI is tought from the examples provided only by us with our fallacies and weaknesses. Will it be fallable by design then?
• Can anybody give me a rational explanation why we need to exist on the Earth? If we don't have it, why would you think AI invented by us should have one?

I think the mejor fallacy of gAI is it has no emotions and empathy to human beings. If built on a pure rational basis I don't see a good reason for it to treat us as necessary addition to its wellbeing. Thus I think we need not only how to teach it learn, but how to teach it feel as well.

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.

DDD summary book

For those lazy or just struggling to find enough time for reading the full version of the DDD book find out this prune summary. The book is definitely worth reading for software engineers and architects. It describes the basics of modeling and how to model business processes with business goals in the first place. I consider it to be on the same shelf as Martin Fowler's book PEAA.