The Paradox of Success

The “paradox of success” can be summed up in four phases:

1. When we have clarity of purpose, it enables us to succeed at our endeavor.
2. When we have success, we gain a reputation as a “go to” person. We are presented with increased options and opportunities.
3. When we have increased options and opportunities, we have increased demands upon our time and energies, it leads to diffused efforts.
4. We become distracted from what would otherwise be our highest level of contribution. The effect of our success has been to undermine the very clarity that led to our success in the first place.

The pursuit of success can be a catalyst for failure.
===
Success can distract us from focusing on the essential things that produce success in the first place.

Software Architects Need Feedback

"Typically, [architects] are farmed out to various projects as consultants, with the aim of ensuring that the project takes off on the right track and avoids mistakes it might make without the wisdom of the consultants. The intent of this practice is laudable, but the outcome is usually sobering: because the consultants are so valuable, having given their advice, they are moved to the next project long before implementation is finished, let alone testing and delivery. By the time the consultants have moved on, any problems with their earlier sage advice are no longer their problems, but the problems of a project they have long since left behind. In other words, the consultants never get to live through the consequences of their own design decisions, which is a perfect way to breed them into incompetence. The way to keep designers sharp and honest is to make them eat their own dog food. Any process that deprives designers of that feedback is ultimately doomed to failure."

from API: Design Matters

Micro-Services: The Modern Modular Programming Paradigm

Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.

As Service Oriented Architecture (SOA) has become popular the modular programming definition could easily be rewritten to read:

The micro-services style of service oriented architecture is a software design technique that emphasizes separating the functionality of a service into  independent, interchangeable services, such that each contains everything necessary to execute only one aspect of the desired functionality.

The term modular programming was coined in the late 1960s. It has been a key part of good software engineering since.

Here are some positive points about micro-services style of SOA:

• Small, easy to understand code base. Because micro-service application is responsible only for one thing, it requires less code, is easy to understand, is easy to reason about, is easy to test, and has less risk of changes.
• Easy to scale. With a large, monolithic application you have to scale everything together. You have to scale the whole thing and waste resources. Whereas, if demand for a particular service temporarily increased then you would only need to scale the specific service.
• Easy to Deploy. With monolithic applications even one line code change require redeployment and re-testing of the whole application. This could be a big problem for many organizations with its high degree of risk and disruption. Deploying micro-services is much simpler because the scope of deployment is much smaller. Plus you know where to look for problems if such arise.
• Ability to use a different technology stack. With micro-services the approach should be to use the best tools and languages for the job, instead of one size fit’s all. The same goes for databases. For example, recommendation micro-services can use neo4j and python because python has a lot of machine-learning libraries; event-processing micro-services may use java and cassandra because of multithreading properties of jvm and high scalability of cassandra. It also allow teams to try new technologies on small services without major disruption.
  Smaller teams. It’s much easier and faster to work with a collocated, small team. Each small team can own micro-service and access other services via high level api. For example, a team in New York can be responsible for recommendation services and a team in India for content micro-service.
• System resilience. If an monoliths application stop working, then a lot of functionality stop working. On the opposite side, If one of the micro-services stop working – only small, particular functionality will be lost. It’s much more simple to build some resilience around smaller service. For example, failure of the order-processing system can be mitigated with message queues.

Regression Testing - Testing Variability

When you need to test that a code change has made an improvement or, at least, didn't reduce the current level of performance, it is called regression testing. A level of statistical analysis is needed to ensure that perceived differences are not the result of random chance. The rigorous way to accomplish this is to use the Student's t-test to compare the results. The t-test can tell you the probability that a regression exists, but it doesn't tell you which regressions should be ignored and which must be pursued. However, provided the cost of running additional tests a cost-benefit analysis could tell you that.

Check out the Apache Commons Mathematics Library (TTest) for an implementation for Student's t-test.

Get To It

"Our great business in life is not to see what lies dimly at a distance, but to do what lies clearly at hand." - Thomas Carlyle

My sister, Joyce, and I write letters back and forth. It is a bit of a tradition that we include a quote either in the letter or on the back of the envelope. The above quote is what I included with my most recent letter. I picked it because all to often at work it seems that we spend so much time worrying about what may come along in the future that we don't do what lies clearly at hand.


If that seems too short sighted to anyone then I implore you to remember the popular quote of Lao-tzu. "A journey of a thousand miles begins with a single step."

Strive To Fix What You Can

I will admit to sometimes getting frustrated at work when someone doesn't want to work in a specific codebase because they think it has too many problems. George Bernard Shaw said, "If there were nothing wrong in the world, there wouldn't be anything for us to do." The systems that need the most work don't just validate the need for developers but are an opportunity to make major improvements.

I had a friend in grad school who went to work fixing and upgrading Cobol applications at a large financial company. Much of the software had no major maintenance in years. He loved it. He said that everywhere he looked he found things to improve that made him look like a rock star.

When you find yourself in that legacy application that is out-of-date and has little to no documentation. Strive to make it better and people will notice. You might even change people's perceptions of the application.

Quality is #1

A product with poor quality should not be tolerated. Delivering a product at the cost of quality should only be accepted in the short-term. If you are using Agile Methodologies, in the span of a sprint, it is acceptable to deliver what you have at the end of the sprint. This will allow for continued progress and enable the gathering of valuable feedback. However, it is political suicide to continue to deliver a product with poor quality. If there is a quality issue then change your roadmap and milestones to address the quality issue.

Brute Neighbors

One of my more cherished and private possessions is a book - American Prose. It was printed in 1892, and is filled with short stories by American authors. Every so often, usually in late fall or early winter I'll pick a story at random to read. Today was "Brute Neighbors" by Henry Thoreau.

I think it wonderful that a book over a hundred and twenty-two years old is perfectly functional and enjoyable to read. Though I do dread the day when the book becomes damaged from use and age; I think that I'll continue to read from it each year. It has more value to me as a book then a collector's item.

Not Even In The Same Ballpark

Not so long ago, a new Product Manager told me that she also is a programmer... a software engineer. She implied that if she wanted she could be part of the development team. She had just started and I had no reason not to believe her and accepted it as an interesting side note and went on. As time has gone by it has become increasingly apparent that this individual was never a software engineer in the way that my peers are. The comparison is almost offensive in the stark difference and extreme lack of understanding of what a software engineer does.

To anyone reading this:
Please do not say that you are part of someone else's group unless you truly know about that person's group. I've brewed beer and cider a handful of times. I've even had the lucky experience of brewing some stuff that is better than some store bought stuff. But I would never call myself a brewer in the presence of someone like Sam Calagione or Jamil Zainasheff. I've never brewed commercially and have no concept of the constraints involved, and I don't have near the same range of experiences. Notice the difference in tone the following two statements have:

• I'm a brewer like you.
• I've brewed at home.

If they both seem innocuous then here are some example responses, respectively:

• Oh yeah, what bars are serving your beer?
• Since I have never brewed commercially, I do not grok the need for high efficiency sparging, dealing with distribution laws, etc.
• That's cool. What is your favorite style.
• I love Bock beer. And Belgium style. And Kolsch. And Scotch ale. And, oh man, Southern Tier's Creme Brulee stout is just epic. But I mostly make cider because I'm decent at it.

Of course, those responses could go any number of ways but the point is that you can share that you have some shared experience without implying your of the same level. Especially, when you have no idea. Heck, you might be better but you just met so you have no idea.

In short, just be genuine. If you were hired to do a job, focus on that. Don't worry about trying to "fit in" with people in other roles.

How To Make Meetings Better

1.

Improve collaboration in meetings by removing the chairs from the conference room. Researchers at the Olin Business School at Washington University in St. Louis used body sensors on two groups of participants and found that team members who stood were more engaged, less territorial about their ideas, and generated more creative results.

http://news.wustl.edu/news/Pages/27031.aspx

2.

Start your longer meetings by giving everyone a chance to share what they need to do or to say to be fully attentive. One person might have a specific question. If they have more than one then they should have asked their set of questions beforehand. Another person might need to leave at a specific time. Yet another person might just want to vent about being in meetings all day. If the same person makes this complaint often then they might not be ready to be included in these meetings.

3.

Make more meetings more engaging by making them voluntary. I find it pretty satisfying if one of my meetings finishes and no one leaves. The meeting has developed a life of it's own.