Is complexity justification for itself?

Have you ever had this conversation?

"Why is this so hard?"

"Because our environment is so complex."

"Well, why don't we just use [INDUSTRY STANDARD XYZ]?"

"Because our environment is so complex; in order to support the pieces we have already we need to take [COMPLEX SOLUTION ABC]. The simple approach simply would not work."

"Wouldn't it be better to take the simpler approach and adjust the current complex components?"

"We can't, we have always done it this way."

Etc. Etc. Etc.

I hate that conversation. It get's very old.

Complexity does not justify further complexity. It may be hard... it will be hard to get out of that mode of thinking but it is necessary. While a complex environment may exit it doesn't mean that industry standard approaches won't work. It is my conjecture that complexity has become cultural.

Simplicity is the ultimate sophistication. - Leonardo daVinci

Simplicity is hard. This can be seen if you look at code from an experienced developer versus a new developer. Generally speaking the code will be more readable, more understandable and simpler. (Even though the algorithm may be more complex the elegance of the implementation makes it easier to understand.)

I will end with this quick request. If you hear someone using complexity as justification for further complexity call them on it. Press to see if a simpler approach is possible. It may be a little harder in the short term but in the long term it will pay off greatly.

Is the question more important than the answer?

Right now I have 4 books I am shifting time between, one of them is "How to Think Like Leonardo da Vinci" by Michael J Gelb. One of the items brought by my Gelb is curiosity as one of his seven steps to thinking like da Vinci. In essence this particular step is all about asking questions. It is an interesting thing that as we grow and are educated we are thought to not question but rather to answer.

Gelb states, "In most cases, schooling does not develop curiosity, delight in ambiguity, and question asking skill. Rather the thinking that is rewarded is figuring out the "right answer" - that is, the answer held by the person in authority, the teacher."

In school we learned that the answer was more important than the question. Not just that, but that the answer that is desired by the prevailing powers that be is the answer we want to give. If we don't then we don't get good grades, if we don't get good grades we don't have as many options, if we don't have options we can't make as much money, if we can't make as much money then we can't have as good of a life... or something along those lines. People get caught up in trying to give the answer that their boss want's to hear. Or not asking the questions that they feel should be answered simply because that is how they have been trained, or that is the prevailing culture of the company.

What get's lost in the shuffle is the desire to question. The Wonder of the Universe. We all think of small children and asking why. For those that are not parents kids don't ask the questions you expect. Sure they ask why the sky is blue... but they also ask if everyone sees the same colors, how the sunlight travels if it doesn't have a car, and random things that simply don't make sense to the educated and it would never even have occurred to us to ask.

As I think about Engineering I think that this curiosity and desire to ask questions of what if and how and why are key to a successful engineering approach. In order to build effective systems we need to understand how things operate, what happens when something outside of the expected happens, how the system will respond to it, etc.

From these questions we come up with what we are calling Operational Models that show the threads, the Pressure Points, the potential hot areas of any application. From this we can plan capacity, plan protection and plan impact to downline and upline systems.

So, here is an exercise for you. (Borrowed freely from Gelb) Take a piece of paper (da Vinci. always kept a notebook or note pages with him, now called the Codex Arundel. Bill Gates paid 30 million dollars for some of them, the Codex Leicester... who knows, if you keep one maybe it will be worth millions some day) and write 100 questions on it. They can be about anything. Just let your mind wander. Then look for themes. Then explore those themes.

Sacred Values, Organizational Hypocrisy and Innovation

I recently read a Cutter Edge email (if you are not familiar with Cutter go check them out) that I thought was very interesting. In case you haven't been keeping up with the news Toyota recently passed Ford in the list of World's Biggest Auto Makers. They are also putting focus on GM and trying to get to the number one spot. The Toyota Lexus brand recently took the top spot in 11 of 19 vehicle categories. The reason that Robert Charette wrote the Edge article is not all of these wonderful accomplishments but rather, what they are doing in response to a challenge.

Toyota has recently had some quality problems manifesting in an increase in recalls. The company has a choice with their recent success to continue to press on and work through these issues as time allows or to slow down and put focus on ensuring they are addressed. Given that they have come so far and are so close to their goals it has to be tempting to say that these are just short term problems and to press on as most any successful, large sized company would and even the public markets would expect.

But they are not. Toyota has given an apology for the problems and stated "There can be no growth without quality improvements." They have even assigned executive VP Akio Toyoda, grandson of the company's founder to be responsible for quality improvements. As part of their drive to increase quality Toyota has started several initiatives ranging from adding systems to track repairs to cars even after the warranty expires to hiring more engineers.

You read that right, in this age of continuing layoffs they are hiring more engineers.

As the company grew they added new systems, CAD tools, that would increase engineer productivity and reduce the number of physical prototypes needed. Toyota is recognized as the creator of Lean processes and manufacturing (and it is interesting to note that the problems are not in manufacturing, but in Engineering) However, there are limiters to what tools can do and with the increase in the number of initiatives this meant fewer eyes were cast on each design and "boneheaded mistakes" found their way through the system.

Robert discusses these items in the context of corporate risk management but also mentions Sacred Values and Organizational Hypocrisy. These are when a company says that something is important to it and then does not act like it in reality.

I am encouraged by the fact that companies are having new and creative programs such as Hack Day and other things currently under way in companies. To me this shows that at least some companes take innovation seriously. The question though is, do we take it seriously enough? Many of us are already working well over 40 hours a week on projects and problems that have been funded. Finding the time (and energy) to be transformationally innovative, not just iteratively innovative is hard to do and rarely encouraged.

The real proof will be when something difficult happens. Innovation is, by it's very nature, disruptive. Especially in large companies with business to protect. Read a recent blog post on how "Survival is the Mother of Invention" on the difficulties IBM went through for a very real example.

Engineering Poetry? Limericks? Haiku?

Poetry for Engineers? I know.. it sounds a little out there and I am not just cheating and saying an Engineering degree from the University of Limerick. This was just too good of a follow up to the whole idea of there being other non-technical abilities that make someone a better programmer or Engineer. I encountered a news article on how Georgia Tech is now teaching poetry to their Engineers. By making this part of the curriculum the school is trying to teach students how to leverage their full mind and potential. One of the analogies that was used when describing good poetry could also be applied to good code.

"If something is good, it will stick around. That's just a fact of history. If something is not good, it will dry up ... "

Long, long pause for dramatic effect.

"And it will blow away."

Nicely said professor Lux.

The other aspect of this that I think is interesting is along the same lines as the recent flurry of music posts. Poetry is historically a right brain activity with some left brain rules applied for form. When done well it is a blending of the whole brain to get an answer. As pointed out by Dan Pink in his excellent book Whole New Mind the ability to use both halves of our brain is now required to be successful. If you are a rule and "left brain" only type of person... eventually your job will be automated or offshored. But if you can utilize your whole brain there will ALWAYS be work for you.

Consider this the next time you have to clean your toilet. (I know that seems like a sudden context shift, but humor me for a moment) Your toilet brush is no longer just a toilet brush. That Target toilet brush is not just a toilet brush, it is a designer toilet brush, selected from over 5 different hues and tones from shiny red to stainless steel to be uniquely you. That is how much of a world of abundance we now live in... we now include design in our toilet brushes. (No I did not enter a contest to see how many times I could put toilet brush in a post... but once I got started I just couldn't stop) Our parents and certainly our grand parents were thrilled if they could own one home and one car. Now... many of us have multiple cars.

Consider these things as you come up with your next personal development plan. Are you just looking at adding another language? Are there other things that you could take on to grow into a more well rounded and whole brained person?

You have to feed a lion to know how hungry it is

I am reading a book (Competitive Engineering by Tom Gilb) which has a lot of information on requirements as well as systems engineering. Although the book itself is a bit of a Tome (read as difficult to get through in spots as it pontificates on things I (and most of the world) don't care about) it has some bits that are wonderfully insightful and keep me reading. I thought I would share a few of what I thought were fun quotes and then expand on them a little.

You must feed a lion to know how hungry it is. In the software world this can be stated as unknowable complexity, often described with the phrase "we don't know what we don't know". In essence what this is saying is that you can't have perfect knowledge up front about exactly what requirements are going to be needed and how exactly things should work. In Agile we address this by defining the set of stories then prioritizing and delivering early and often. Do the valuable things first. Many projects get their funding cut due to one thing or another. Projects that are delivering value, regularly not only fight the complexity problem by addressing things in bits and hitting the "goodies" first but also pay as they go allowing business to see value along the way thus reducing their chance of a cut. This statement also applies to the use of Spike solutions. If you don't understand something well enough to give an estimate... don't. Do a spike solution, learn about the problem, reduce the risk and make an estimate with more knowledge.

Even gourmet decays. Another way that I have described this is with the statement regarding requirements that "it's not that I lied, it's merely that the facts have changed since last I told the truth." Requirements change. Any requirement, as soon as it is completed begins to become less and less valid as the business environment and the world the requirement was created for changes. Again, in Agile we address this by delivering value early and often and only going into the nth degree of depth when it is needed. By working with customers on the most valuable items in the backlog for each iteration we are able to keep our requirements as fresh as possible, work on the "right things" and able to more quickly adapt by picking and choosing the stories that have the most value to us at that time. Recent research has shown that only 20% of the functionality in software systems gets used often or always... lets focus on getting that part done first.

Stop the world, I want to get off. We could no sooner say that we are tired of the world spinning and stop it than we could freeze all requirements up front and hope to deliver something that will truly make our customers happy. In Agile this is again dealt with by working on the most important stories first and prioritizing and selecting the new "most important" stories at the beginning of each iteration. By attempting to freeze all of our requirements and not updating them we would cause far more problems (not to mention churn or analysis paralysis) than if we just updated our requirements.

Fantasy Sports

I have now officially fallen into the psychotic reams of people who are participating in Fantasy Sports. It started innocently enough with a begged request from a friend at Church who needed "just one more person to have an even number". As I started exploring just what I have signed myself up for I ran into an interesting example of what I posted about just the other day.

Hockey has always been my favorite sport. In part because the whole idea of Hockey has always been about the team to me. You can have one guy who is super awesome and he will be fun to watch but it takes a dedicated team to get the wins. As Ken Hitchcock used to say "Hard work beats talent when talent doesn't work hard."

And now... here I am looking at stats as the sole indicator of how good of a player someone is. Where I have always been an unabashed homer who cajoles the call guys for being biased if they say anything negative about my team... now I find myself looking at who is playing who and rooting for individuals so my "team" can win. Before my rules were clear... if they were wearing the wrong sweater they were evil and obviously a cheating fake, now things are more complicated. I used to be able to know they were evil by the Red Wing logo on their chest (until they left as a free agent and signed with our team at which point their sins were forgiven) but now I need to look and see if they are on my roster.

Ain't life fun? Sorry for this non-technical ramble of a post but I just found the whole thing particularly humorous given how quickly I find myself living contrary to my own post.

Are we a world of individuals who don't understand teams?

The USA lost to Europe in the Ryder Cup this weekend. According to the news here in the states between this and the loss in World Basketball competition we have too much focus in the US on individual success over team success and this is hurting the U.S. in international sports. This has even been observed in the UK press. (By the way, congratulations European team, well done)

Why do I bring this up? Especially when you consider I don't watch golf (I enjoy golf but my game is one that makes other's feel better about their game) and I have an actual spoken distaste for basketball. (They just mess up my ice no matter how amusing Cuban is.) It's not because of a sudden care about international sports. It's because I thought it brought up some interesting points about teams and teaming.

As a race of humans we have not always been about the individual. Michael Gelb (yes, another mind mapping guy) point out in an article he wrote for Create Magazine that "Prior to the Renaissance, the notion of individuality didn’t exist, because the concept of individuality, as we now understand it, didn’t exist. Paintings, for example, remained unsigned, and painters, anonymous, because the individual was considered unimportant. All creative power was vested Above."

We all have a desire to do our own thing. Be our own person. Contribute on our own merits. Make our will known and get the recognition we deserve. etc. etc. etc. I don't think that in and of themselves these are bad things. They are probably good things. But teamwork is also something that is critically important.

Teamwork is the process of taking a group of individuals and making them capable of more than they would be capable of by themselves. Some of the most valuable individuals in any group are the ones who make that synergistic bonding possible. On sports teams these are the leaders of the team, the ones who inspire everyone when things are going poorly. In business they are the people who others watch and take lead from. The positive (and sadly sometimes negative) influence that raise everyone's mood, performance and vision.

It takes a bit of self-sacrifice to put the team ahead of the individual. This stems from recognition and a desire to personally excel. In an authoritative "Boss, Rules, Controls" culture individuals are actually disincented to promote the team. That is why we all need to encourage and "be the change we wish to see" (Mahatma Gandhi) when it comes to teamwork.

Do you know someone who helps other people around them become their best selves? Talk to them today. Say Thanks.

Tenets of good SOA programming

Today's post is a follow up to my post on complexity being a math problem. SOA programming just like Object Oriented programming has a select set of steps and principles that need to be followed in order to ensure the most effective use of these technologies.

Most programmers can spit out the rules of good Object Oriented design in their sleep. These same principles are very similar in my opinion to the tenets for good SOA design. OO Tenets are Abstraction, Encapsulation, Inheritance and Polymorphism.

• Abstraction means ignoring irrelevant features, properties, or functions and emphasizing the relevant ones… relevant to the given project. This also covers Data abstraction simplifying.
• Encapsulation means that all data members (fields) of a class are declared private. Local use methods may be private too. The class interacts with other classes (called the clients of this class) only through the class’s constructors and public methods.
• Inheritance states that a class can extend another class, inheriting all its data members and methods while redefining some of them and/or adding its own. Inheritance represents the is a relationship between data types. (e.g. a FemaleDancer is a Dancer)
• Polymorphism ensures that the appropriate method is called for an object of a specific type when the object is disguised as a more general type. (e.g. Square being used like a shape)

To keep things simple and play off the magic number of four tenets these are

• Boundaries are explicit
• Services are autonomous
• Services share schema and contract, not class
• Compatibility is based upon policy

Boundaries Are Explicit basically means that a caller of a service need only (and for that matter, should only) understand the interface to a service. It does not need to know what is going on behind the scenes nor should it care. This enables the implementation to evolve over time without requiring changes in its consumers. This abstracts complexity and is core to making SOA work.

Services are Autonomous is setting up services so that they are independent and able to function on their own. While a set of services becomes part of an orchestrated whole and thus build a system they should be designed in such as way as to be as self governing as possible.

Services Share Schema and Contract, Not Class accessing systems should care about the data and schema that are received and the data that is required for a service to be used. This should be viewed as a contractual interface between the caller and the service. Callers should not expect a Class file from that service as services are about data and schema not specific implementations. When integrating systems and performing remote calls the expectation and integration at the class level is fine, but it is not a service.

Compatibility is Based on Policy means that functional compatibility needs to be managed. Versioning of services and ensuring that they are backwards and forwards compatible is a wonderful goal but may not be fully achievable. This needs to be accepted and managed through policy.

Looks like there is ample ground for posts on this topic. What do you think? Do these Tenets make sense? Should there be others?