On Intelligence: How a New Understanding of the Brain Will Lead to the Creation of Truly Intelligent Machines by Jeff Hawkins is a truly fascinating book. It delves deep into how the brain works and why it is so hard to train a bot to do normal human things. Our brain is able to make low-level sensory predictions about what it expects to see, hear, and feel at given moment and it does all of these task in parallel. Here are other things I found interesting.
- Deep blue beat Garry Kasparov at his own game, chess, but the successes were hollow. Deep blue didn’t win by being smarter than a human it won by being millions of times faster than a human, deep blue had no intuition.
- These successful AI programs are good at one thing and one thing only just like a calculator is great at math but can’t do anything else.
- A computer just mindlessly executes instructions. It doesn’t know any more context than we have given it.
- Our intuition is often the biggest obstacle to uncovering the truth. Intuitive but incorrect assumptions keep us from seeing the correct answer.
- The strengthening and formation of synapses is what causes memories to be stored.
- The best ideas in science are almost always simple, elegant, and unexpected.
- We teach children we have five senses – touch, smell, sight, hearing, and taste. We really have more vision is like three senses motion, color, and luminous. Touch has temperature, pressure, pain, and vibration.
- The neo-cortex is infinitely smarter than any computer.
- An artificial intelligence strategy to open every door is impossible. Every attribute a door can have has to be in a database, weight, hinges, handle location, etc. There would need to be similar lists for every object in the world. Your brain makes low-level sensory predictions about what it expects to see, hear, and feel at any given moment and it does it all in parallel.
- Correct predictions result in understanding. “the door is normal” incorrect predictions result in confusion and prompt you to pay attention. “the door is too light” the door knob is moved, etc
- When you miss a step you know immediately. If your foot misses its intended target by even a fraction of an inch you know something is wrong.
- If you get stuck on a problem go away for a while and then start again rephrasing the problem as something new.
- Brain uses memory and current context to predict what is written, words and letters that are unrecognizable on their own are easily recognized in context. Pattern matching with computers is not sufficient to the task.
My personal notes from Leading the Transformation by Gary Gruver
- Additional reading – Many specifics referenced in this book are leveraged from a case study of transformation at HP, detailed in A Practical Approach to Large-Scale Agile Development, by Gary Gruver, Mike Young, and Pat Fulghum.
- How teams come together to deliver value in large organizations is a first-order effect. How individual teams work is a second-order effect
- Done means
- feature is signed off
- defect free
- test automation is complete
- Software development is such a discover process that many assumptions made in planning can quickly become obsolete during development
- Capacity of an organization to absorb change is the biggest constraint to rolling out improvements
- Should always set objective and review at the end of each iteration
- When estimates are off many organizations react by spending more and more in planning instead of focusing on delivering software
- Instead of scolding people who commit on a red build, create a process that eliminates the problem
- Usually roll back the last commit
- Many organizations ask their manual testers to learn to automation what they have been doing manually for years. Some orgs buy tools to record what the manual testers are doing and that’s even worse
- Record and playback is awful because if any UI changes the whole test is trash
- An acceptance test should test one thing and one thing only.
- All configurations should be in version control
- You can automate checking successful deployments by querying your log management software for a successful deployment
- Developers want to do a good job, and they assume they have until they get feedback to the contrary
- ROI on DevOps is substantial but you will never achieve full benefit until you get your automated testing built out and integrated into the development pipeline
- Applying DevOps principles at scale really requires the executive to drive the cultural and technical changes for improving the stability of trunk. This is vitally important because of the productivity gains that are possible when you eliminate branches and integrate all work across the teams on trunk. To get your code trunk to this level of quality and to keep it there, you need to begin using a CD pipeline with both code and component-level gating. This pipeline must incorporate a robust test automation framework. You will need to have component-based automated tests. Executives will need some simple metrics that are auto-generated each day to understand what is working and what is not so that they can focus resources in the right place every day.
My personal notes from The Lean Startup by Eric Ries
- Identify where you’ve made assumptions instead of using facts. Make your assumptions facts by getting customer feedback
- Early adopters are suspicious of something with too much polish.
- If it’s ready for everyone to adopt how much advantage can they get?
- Additional features or polish added is a waste
- When in doubt simplify.
- Any additional work beyond what was required to get feedback is a waste
- Customers don’t care how much time something takes to build they care that it solves their needs
- Everyone thinks their recent innovation is why the numbers went up. It’s everyone else’s fault when numbers go down.
- Toyota Andon Cord
- Defective change is removed immediately and automatically
- Everyone on the relevant team is notified of the problem
- Team is blocked from introducing any new changes
- Root cause analysis performed
- Dealerships sometimes have just in case inventory which cost a lot of money to keep stock on hand that we never be needed switch to just-in-time inventory and only have a one what you need
- Use 5 why’s? to answer questions
- “We didn’t do x”, “Why didn’t you do x?”
- “We didn’t do x because of y”, “Why didn’t you do y?”
- LTSE long term stock exchange
My latest project was moving a bunch of applications from running on WebSphere using Java 6 to running on Liberty running Java 8. For the most part this was pretty straightforward, but one major issue we ran into was a bean defined like so
<bean id="environment" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="java:comp/env/string/nw/environment"/>
What the heck does java:comp/env/string mean?
Turns out it’s pretty obvious once you know. It’s a JNDI Entry in Liberty (Namespace binding in WebSphere). You need to enter a new JNDI entry with a name of string/nw/environment with a value of dev, it, pt, prod, whatever your environment name is. This is generally something you’d add to a properties file, but considering this app is crazy old maybe that wasn’t an option.