Mark Suster, a two-time entrepreneur turned venture capitalist, is doing a series of posts on his blog about Entrepreneurial DNA. Mark’s series is going through 11 key attributes that successful entrepreneurs need to have. I have enjoyed reading the series thus far but I think Mark left out the most important attribute of all.

Mark’s list begins with what he believes to be the key attribute: tenacity. Quoting from the article:

Tenacity is probably the most important attribute in an entrepreneur.  It’s the person who never gives up – who never accepts “no” for an answer.  The world is filled with doubters who say that things can’t be done and then pronounce after the fact that they “knew it all along.”  Look at Google.  You think that anybody really believed 1999 that two young kids out of Stanford had a shot at unseating Yahoo!, Excite, Ask Jeeves and Lycos?

I agree with everything Mark is saying about not giving up, but I would disagree at its the “most important” attribute. In my mind the most critical requirement for any entrepreneur is whether they Get Things Done.

Let’s Git-R-Done

Larry the Cable Guy is an American Redneck comedian famous for the phrase, “Git-r-done”. In my mind, this should be the rallying cry of every founder as they work through obstacle after obstacle in their quest to start a company.

Getting this done is so key you might think of it as a prerequisite to starting a company. If you can’t get things done, it doesn’t matter how much tenacity you have. It doesn’t matter how hard you work. Nothing matters if you can’t move the ball forward.

In real world terms this can manifest itself in many ways. Ask yourself these questions:

• Am I working on the absolute most important task I could be?
• Am I working on something that will eliminate an obstacle to my success?
• Am I avoiding the hard choices that need to be made to evolve my company and product?
• Did I just walk away from the most important opportunity in the early life of my company because I thought it was impossible to grasp?
• When you see an obstacle in front of you is your initial reaction anything other than to move forward, finding a way through, around, or over the problem?

Seemingly every day or week or a young startup’s life the founders are presented with new and unknowable challenges. In fact, I tend of think of this as an indicator of potential success. If you don’t feel as if you’re on the razors edge then you’re not pushing hard enough.

Getting Things Done at Metreos

At Metreos there was one specific event that was critical to our success. It was a Monday morning, if I recall correctly, and we got a call from a potential customer. At this time, we had no customers at all, just a bunch of people kicking the tires. This customer had been evaluating the product but we couldn’t get them over the line in terms of buying. Their question to me was simple, “We’re about to buy a product from one of your competitors. We like yours better, but there is a key feature that is missing. If you can add that feature by Friday, we’ll go with yours instead.”

Now, calling what they wanted a feature is really doing it a disservice. What they really wanted was an entire application. You see, at Metreos we build development tools. This potential customer wanted to use our tools but they also needed this particular application more. So, the customer decided to see if they could get both: Metreos would very quickly build the application using our tools, and the customer would buy both the application and the development platform they wanted.

The only problem was the application they wanted could easily take 3 months to build and they had given us a week to prove the key tenet of our sales pitch, that using our development tools would significantly reduce the amount of time required to build these applications. Of course, in my mind, there was no way we weren’t going to get this done.

Late Friday afternoon we shipped the application to the customer. It certainly wasn’t polished, but it worked and it proved to them that not only did we really want their business but the underlying tenet of our product, that you could very quickly build telephony applications, was true. This was our first customer, and they went on to be our biggest and best customer as well.

Getting things done is the most important attribute any entrepreneur can have. If you can’t get things done then no amount of hard work will make you a success.

The modern Internet citizen is faced with what I’ll call a participation dichotomy. The social web, through its emphasis on connections and sharing has emerged as a predominate force driving findability on the web. Unfortunately, to participate in this valuable human filtering of information one must connect and follow vast streams of input data. This has the side effect of creating massive amounts of noise, making the goal of learning potentially more time consuming than before.

During Internet 1.0 we found things on the web in two ways:

1. A personally directed effort through search and browsing
2. Sharing amongst directly connected, real-life peers

Contrast this today where there is a third option, becoming more and more dominate: the sharing of information amongst loosely connected peers—namely people you’ve chosen to follow via asynchronous means (Twitter, RSS, whatever).

My Google Reader is filled with over 200 subscriptions to blogs and news outlets. I’m fairly selective about what I subscribe to, but even this modest amount of daily input is overwhelming. I follow approximately 800 people on Twitter, and that is beyond manageable. Why do I do this and why not reduce my information input by unsubscribing and unfollowing? Simply, that would disconnect me from the social web, something that I find value in participating in. Even though I can’t read every incoming tweet, I find nuggets of wisdom on a daily basis. And even though I can only scan my Google Reader, I still find valuable information.

Unfortunately, it takes entirely too much time to maintain. This is the Participation Dichotomy of the Social Web. We are motivated to participate, connect, and follow so that we can gain the benefits of human filtering and information sharing; however, the tools to manage the information inflows have not evolved to handle the amount of data we are dealing with on a daily basis. The noise level grows in proportion to the amount of input, and eventually that noise level makes finding personally valuable information in the input stream unbearable.

There are ways to solve this today. You can meticulously organize your inputs, so that they are categorized based on topic or priority; or, you can delegate the task of first line filtering to someone else, and only read the information of value that passes the equivalent of a narrow-band human information filter. I find both of these options inadequate, unscalable, and potentially disjoint to the goals of the social web.

First, it is very hard to maintain accurate categorization on incoming data. I follow people, and those people share a vast array of different types of information. One person might share links to articles about entrepreneurship, machine learning, and NBA basketball. Categorizing this manually is next to impossible, especially without help from the sharer in terms of tagging.

Second, having an assistant filter my information is, personally, unappealing. Delegating the task of learning to another human, and allowing them to judge whether a piece of the web is worthy of my attention goes against my nature. I expect that I would find it challenging to effectively manage the configuration of that person so that they could effectively filter for me. My interests are dynamic and the priority to which I would assign each changes daily. This is not a scalable solution.

Fred Wilson, a prominent venture capitalist and blogger, recently wrote a blog post entitled “People First, Machines Second“. I found the article very interesting and the discussion within the comments even more so. I think Fred is right, the first level of filtering on the Internet needs to occur within people. This has been happening for a long time: Google’s PageRank algorithm emphasizes the supposadly human action of linking to rank the search results returned. To summarize Fred’s point:

Someday machines may be smart enough that they don’t need humans to give them cues, but today I believe the state of the art in machine intelligence right now is ‘humans first, machines second’ as Google did it… [You] need humans first, then the machines can take over.

This filtering is happening across the social web everyday on Twitter, in blog posts, and on Facebook. Information of value is being shared by people who found utility in a site, blog post, PDF article, or YouTube video. It is this sharing that is the fuel for the social web’s engine.

How then, do we evolve our tools to handle our personal information inflow? The tools need to become smart. Machine learning, through personal reinforcement, should be used to create a dynamic information filter that I can apply to my daily life. Science Fiction is riddled with examples of this. One of my favorites comes from Peter Hamilton’s Night’s Dawn Trilogy. In it, the future-people have “e-butlers” that manage the information flow to them on a continuous basis. BTW, the books are great—I highly recommend them.

This is different than having a human filter my daily information in-flow because the tool can continuously learn what’s interesting to me. Online learning algorithms already exist and can continuously learn and adapt. The key to making this all work is the passivity of filter in terms of feedback. I don’t want to always have to tell the tool what’s most important to me as that changes. I want the tool to do its best at learning, and then ask me to reinforce (positively or negatively) whether it made the correct choice.

Building such a tool is not trivial from either an algorithm, technology, or user experience standpoint. That’s probably why it has yet to be done in a broadly successful way. In my mind, this represents a major problem with the scalability of the social web and will, in turn, be a large opportunity for smart entrepreneurs in the next decade.

[photo credit: striatic]

Thought I’d share this beautiful info-video from the American Museum of Natural History. Our human brains simply can not fathom the scale at which the universe operates. Amazing.

I particularly like the most macro view of all mapped objects. It is almost fractal-like: I feel as if we could zoom in our out forever and always see complex beauty.

[Thumbnail image of Andromeda galaxy courtesy of: gsfc]

The Holiday Season is finally here, beckoning the close of another fruitful year. For me this is always a nice time to take a step back and reflect on the year gone and the year ahead. 2009 truly was a great year—Personally, it brought my family a new joy in our 2nd daughter; a new opportunity and challenge with the formation of my new company, LugIron Software; and finally, it marked 10 years with my lovely and beautiful wife, Tiffany. Amazing!

Worldwide, 2009 was also full of all sorts of terrible and wonderful things. I’ll let the media focus on the bad stuff that happened, and instead I’d like to point out a few truly remarkable and inspirational events that are near and dear to me.

Most people know that I’m a space buff. I’d love to have the opportunity to one day do what Elon Musk has done: become a successful entrepreneur and parlay that success into a great enterprise with the potential to change the world as we know it. Given that, I thought it’d be fitting to summarize three of the years most wonderful achievements and discoveries related to space and our undeniable urge to explore.

Cutting the Cord and Turning a Profit

Getting to space has far too long been an overpriced journey. Now that entrepreneurs like Richard Branson and Elon Musk are getting involved the future of space flight is looking bright. I now feel confident in saying that private space exploration is starting to happen and it’s going mainstream. Some highlights:

• Sir Richard Branson and Burt Rutan unveiled Virgin Galactic’s spaceship: SpaceShipTwo. This craft, along with its mother ship, Eve, will start taking paying tourists to the edge of space in 2011.
• Elon Musk and SpaceX are readying the Falcon 9 launch vehicle for its first flight after finding success with Falcon 1. This rocket, along with the Dragon will be able to take cargo and people into space and to the International Space Station.

The Obama administration has shown a willingness to encourage the private sector to get into the space game. I hope they continue their support and begin a long standing tradition of US Government letting loose the reigns of space exploration.

Water is the Juice of Life

Getting to space is one thing, staying there is an entirely different matter. Two major discoveries this year have given us hope that once we master affordable launch vehicles we’ll be able to establish a truly permanent presence in space. Significant amounts of water were found and confirmed on both Mars and the Moon.

An Impact Crater Showing Water Ice on Mars. These two images were taken on October 2008 and January 2009. Credit: NASA/JPL-Caltech/University of Arizona

The Mars discovery is notable because not only is the water very pure but it was found in large quantities beyond the polar regions. The water ice on the Moon could make it significantly easier to establish a permanent presence there and it was found by a spacecraft that only cost $79 million. Space exploration doesn’t have to cost billions!

Not Just a Waste of Space

Finally, near the end of the year we were treated to the discovery of GJ 1214 b—the most earth like extra-solar planet discovered to date and it’s within our cosmic neighborhood, just 40 light-years away. I like to think that somewhere Carl Sagan is sailing through the stars smiling as we learn to believe what he always knew: there must be billions of planets and millions of alien species out there, the numbers simply can’t be ignored.

With that I’ll close the my 2009 retrospective with an inspirational viral video that surfaced this year. Carl Sagan and Stephen Hawking… singing. Amazing.

Diving Into 2010

I’m not big on dwelling on the past. I like to reflect, but I’m very much of a charge ahead kind of guy. I won’t make any predictions about the coming year, but I’m sure it will be filled with many challenges and opportunities. For me and my family, I think this will prove to be an important year.

The Marascio 2009 Christmas Card Photo

I hope your 2009 was as good as mine! Here’s to 2010—let’s get ‘er done.

It’s been quite some time since I’ve published anything. I’ve been all consumed by LugIron and family. I’m going to be re-tooling the site soon, and will hopefully be able to publish more regularly.

The LugIron blog gets updated quite a bit, sometimes by myself. Also, I’m becoming more active on twitter, so you should follow me there.

Look for a new site design and more regular updates soon.

According to the Austin American Statesman, in the past six months the Teacher Retirement System of Texas has lost $34 billion representing a decline in value of about one third. From the article:

The Teacher Retirement System of Texas trust fund lost more than $34 billion in the past six months – a drop in market value of about one-third, according to an actuarial report released Friday.

The system, one of the largest public pension funds in the world, now has only 68 cents for every dollar that it needs to cover promised benefits to its 1.2 million members over the long term; in August, that number was 90.5 cents.

The financial markets fell 40 percent overall during that same time period.

Sure they like everyone else lost money, big surprise. What sort of perplexes me is that in search of a nominal 8% return (as indicated by the article), they were actually taking on enormous risk. Heck, I wouldn’t even be surprised if the TRS investment committee members were proud of themselves for beating the market—after all, they only lost 33% while the overall market dropped 40%.This isn’t unique to TRS, it’s more of a broad misunderstanding of the risks involved when making what are, essentially, “long the economy” investments.

I first heard that term while listening to a very successful investor, Salem Abraham, talk about his fund. Many really great investors have long been overlooked because they took a different approach than blind faith in the ever increasing equity markets. Usually the argument against investors like Abraham would have been based on the fact that they traded futures. Simply because the futures markets allow one to more easily shoot themselves doesn’t mean that talented folks like Abraham should be dismissed. After all, if you now look at their risk adjusted return compared to the S&P, it’s actually better.

If there is one good thing that I would love to see come out of the recent market turmoil, it would be that the equity markets are just as risky, over the long term, as other “alternative” investments like managed futures. Knowing this, investors should seek out diversification between asset classes. And this means more than just an equity/bond portfolio.

As a final note, you should go watch Elizabeth Cheval’s presentation on correlation and why you should be looking for negative correlation in your diversification. If you watch it, it’ll open your eyes. Or, you might simply dismiss it, and wait for the next market implosion.

The time has come: yesterday, December 31 2008, was my last day at Cisco. In my mind, my tenure at Cisco was about completing what we started eight years ago with Metreos. Cisco purchased Metreos after we had been operating for 5 ½ years as an independent company and for 2 ½ years I worked to help Cisco execute on the vision that building enterprise telephony applications and integrating them with business processes shouldn’t be painful. I’d like to think that we were successful in that venture.

Now that I have closed the final chapter of the Metreos (epic) novel it’s time to write a new one. I’m an entrepreneur and I’m certain a new idea, product, and company are what’s next for me. Stay tuned to see what happens.

We’ve all had that moment. You know the feeling, your stomach falls out from under you, your legs go a bit wobbly, or your gut climbs into your throat. It’s an “Oh Shit” moment.

Lot’s of times this happens under relatively benign circumstances. Maybe during a test cycle you realize you forgot some fundamental feature or missed a major requirement. No big deal: just adapt and overcome. However, there are times when those moments are particularly scary.

Building software, especially software that has to integrate with other systems, should always breed a healthy dose of skepticism when diagnosing root cause. What I mean is, there is always a feeling that the problem might not be your own, but in reality, you must always assume that your software is creating the problem, even if it isn’t convenient. Doing otherwise is trying to operate outside of your own sphere of influence: you have no control over the software you integrate with, therefore it is typically a sisyphean task to start there in trying to resolve a problem.

In the many years that I have been building the Metreos/Cisco product that I work on today I have found bugs in other people’s software a mere fraction of the time when compared to my own. It is almost always my fault. I’ve also seen, over and over again, other engineers (some young, some old, I don’t think it is related to your experience level) jump to the immediate conclusion that “it must be xyz in abc’s product” thinking to themselves “there’s no way it could be us”. This is a horrible way to approach problem resolution and root cause identification.

Those really nasty problems almost always happen under the umbrella of a customer found problem. So, coupled with the fact that you’re already facing an “Oh Shit” moment you also have the added stress of knowing that the customer is expecting updates, information, and a fix as soon as possible. An engineer who worked for Metreos’ first customer, and now a good friend, always had something funny to say in these situations:

That’s a dilly of a pickle you’ve got there.

That always made me laugh, but I think the thing that I appreciated about the relationship we had was that he always afforded us the space to work the issue in a logical, diligent, and direct manner. Getting yourself out of hairy spots is much easier when the customer is not being difficult.

So, needless to say, I’ve faced my fair share of pickles over the years. I’ve built up a pretty standard method of analyzing and diagnosing the root cause of the problem. What surprises me is how people try to debug these complicated systems without such an approach. Much of the time you see engineers tossing darts in the dark, hoping to find a solution. The funny thing is, and I’ve seen this first hand as well, is that they might toss one of those darts and see the problem fixed. Unfortunately, without understanding the root cause they never really know whether the real problem is fixed or whether they’ve simply treated the symptom.

Here’s how I typically approach things:

1. Ensure the problem has been reported properly and is being tracked according to your process. If the problem isn’t being tracked you’re doing the customer a disservice. Make sure it’s logged, has a tracking number, and is visible on whatever process dashboard you might have.
2. Confirm your understanding of the problem and formulate a set of plausible causes, if possible. It’s sort of amazing how many times you’re initial understanding of the problem is adjacent to the actual experience the customer is having. Take the time to reconfirm, in painful detail, what’s happening and what’s expected to happen.
3. Analyze available data. If no data is available, ask for data that might already be available by the customer. For example, your standard set of logs that might be turned on in production. Data is critical. Without the data it’s impossible to create a sound hypothesis or confirm environmental events. Many times, people don’t get the data needed because they have some aversion to asking the customer to do work in helping diagnose the situation. If you need the customer to gather network traces from a specific port on a specific switch, tell them so they can do it and get you what you need.
4. Define a decision tree to isolate root cause. You may choose a positive (rule in) or negative (rule out) approach. Typically the approach you choose is based on your confidence level in plausible root causes you’ve identified. Much of the time, this is less formal than it sounds and is driven from gut feel. If X happens then there is no way the problem is A, but if we see Y then it might be B, etc. The set of possible scenarios and ways those scenarios might be confirmed or refuted is critical because it will push you in a specific direction and tell you where you need to instrument your system or what data you might need to gather.
5. Gather additional data required to walk your decision tree. Again, don’t be afraid of asking your customer to do work here. They will respect you for taking a disciplined approach to solving their problem.
6. If you have reached a conclusion based on the decision tree and gathered data, then you have isolated a plausible root cause. Otherwise, go to step 3 and repeat. If you believe you have misunderstood the problem or are no longer able to formulate a decision matrix, go to step 2 and ensure you are not in the weeds. You should end up in a situation that the data has shown you where the problem is, and you are able to confirm the fix works by turning it on or turning it off. Not all problems are as cut and dry, but many are.

Customers respect this approach. In fact, you can make customers love you for following a disciplined, data driven problem solving approach like the one above. A couple of words of wisdom (yes, I said wisdom, does that make me full of myself?):

1. Make sure they know that you’re in control and are on top of the problem.
2. Make sure they know what the next steps are.
3. Don’t be afraid of telling them bad news.
4. Be honest, clear, and direct with the customer.

There is nothing worse than a waffling, weak engineer on the other end of the line when a major customer problem is in progress.

We had no choice but to follow an approach like this at Metreos, and now at Cisco. The system that we have to diagnose is huge, and problems can be caused by everything from a faulty network element to bad software.

Perhaps the nastiest issue that we had at Metreos was one that was caused by a firewall that would behave differently depending on the order in which specific UDP packets were received. We solved this by having the customer take network traces from various points in the network, making sure we had clear good and bad case examples, and doing some good old fashioned detective work. It was stressful, but quite fun and fulfilling once we were able to show root cause. And best of all, in this specific scenario it wasn’t our bug.

The most perplexing thing to me about working in a large company is this concept of Authority Points. I think it might be the root cause of why people always grumble about big companies, especially when they come from a small company background.

Authority Points

You see, when meetings happen in companies of non-trivial size more people seem to be invited because there are a widely diverse set of interests and motivations within the organization. Meeting organizers tend to error on the side of inviting someone rather than not because they fear not including a stakeholder, even if that stakeholder is only mildly connected to the meeting’s topic or goal.

Now, once in the meeting, all of these folks have an urge. Most of the people invited are climbing the corporate ladder. Most folks motivation is to increase their dominion, grow their influence, and be seen as an important decision maker within the organization. To do this, they must earn Authority Points.

People earn Authority Points in numerous ways: they can do a good job, write a good email, execute well on a good project. But the absolute easiest way to earn Authority Points is to talk during a meeting. I’ll call this “harvesting Authority Points” because I see it as being similar to what most MMORPG players do when they are levelling up: they go around killing all of the easy creatures to get gold and experience points.

Why This Sucks

This is bad because it is one of the primary reasons why meetings go long. It is, in my opinion, the primary reason why most meetings don’t accomplish anything. The people who are there to earn their Authority Points create churn by saying things that have little fundamental value to the goal of the meeting. Much of the time, they create work that is, at best, adjacent to the problem at hand:

Authority Points Harvester: I think we should really talk to
some-guy-over-in-another-group because they might have some insight.

Other People in the Meeting: (silently) Groan.

It’s unfortunate, really, but inevitable. The only thing you can do is be aware of these people and what they’re really doing when they talk. You can identify them in any number of ways, but one of the best methods is to try to recognize when someone is saying something that is a mere regurgitation of what has already been said in the meeting. They’re doing this because they have nothing of value to add, but they must be heard because they want to be sure to convert the last hour and a half of meeting time into at least one more Authority Point. Sigh.

Premature optimization: it’s the hater-programmer’s trump card. These days it seems everywhere I look I see these folks yelling, “Stop, you’re optimizing prematurely! Thou shalt perish in programmer hell!” To this I always want to respond, “What exactly is premature optimization, and why do you think I’m doing it?”

It’s funny, really. In the past six months I’ve heard premature optimization thrown about as a reason not to do something at least seven times. So often has it been used, in such dubious circumstances, that I’ve come to realize that the original intent behind this nugget of wisdom has been warped and skewed by hater-programmers with dubious intentions.

According to the ever growing awareness, Wikipedia, Donald Knuth stated the following in the article “Structured Programming with go to Statements” in the ACM Journal Computing Surveys:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

The article on Wikipedia goes on to say:

“Premature optimization” is a phrase used to describe a situation where a programmer lets performance considerations affect the design of a piece of code. This can result in a design that is not as clean as it could have been or code that is incorrect, because the code is complicated by the optimization and the programmer is distracted by optimizing.

This I completely agree with. Premature optimization is, essentially, a way to say that programmers would rather fiddle bits than confront the design of their software critically. I’d even provide an alternate, perhaps more accurate description: premature optimization is optimization without profiling. In other words, you’re optimizing without pinpointing the problem and without the ability to measure the results; however, this doesn’t mean you have to make simplistic choices when faced with a lack of data.

In my opinion this is one of the most commonly misused tenants of computer science today. So often is “premature optimization” used as an argument against proposed solutions, that I have begun to seriously question the rationale and motives behind most people who propose it as a counter-argument in technical debates. I simply think it is grossly mis-applied. Even more annoying is when people actually suggest that language choice is a premature optimization.

Let me provide a metaphor. Suppose you were asked to fetch a ladder for your friend. Now, you’re into ladders. Ladders are definitely your thing. You have three ladders, each a different size: a step ladder, a fixed ladder, and an extension ladder. Each one has its intended uses, and each one has explicit weaknesses. Which one do you take? You can only pick one.

If you’re a premature-optimization-acolyte you pick the step ladder. Why? Well anything else would simply be overcomplicating the situation without sufficient reason not to. The step ladder is small, easy to transport, and most importantly, sort of cute.

Me? Well, I’m no acolyte. Here is how I see it.

The step ladder is basically useless. It fills a very specific need, but is not adaptable beyond that need. It’s useful in that you can reach items slightly above your head, but its primary utility comes from the fact that the step ladder itself can neatly be tucked away, forgotten, behind some counter or under a bed somewhere. Height, my friend, is not its strength.

So, is it the fixed ladder or the extension ladder? Well, that’s easy depending on the answer to the following question: is the fixed ladder of the over-the-top, uber-Little Giant variety? If yes, then pick the fixed ladder and move on. If no, then the extension ladder is my choice.

Did you hear that? That was several thousand hater-programmers around the world gasping all at once. This is what they’re saying and thinking: “You’ve just prematurely optimized the solution. There was no data to prove that you needed a ladder that could extend to 42 feet.” Bah!

Humans, especially programmers, like to latch on to things we believe we understand. This precept of truth from Dr. Knuth is one of those things. Premature optimization is bad, but inappropriate application of the precept of premature optimization is, IMO, much worse. Why? It suppresses good ideas and creative thinking.

The ladder example provided above is straightforward. A ladder is about height. When asked to choose a ladder without sufficient data as to the height of the area to be reached pick a ladder that provides, in this order, the most flexibility and the most height. If the ladder is a Little Giant then pick it, that thing is amazing, 24 ladders in one! Otherwise, pick the ladder that provides the most height, they can almost always be positioned to reach a lower point, but can very, very rarely (at least safely) be positioned to reach a point above the maximum height of the ladder plus the height of the individual.

How does this apply to software? Well, more often than not, technology, tool, or design choices are changed because the argument against premature optimization is used to argue against what was simply a decision to favor flexibility, or as I call it, a Prudent Foundation.

Prudent foundations are simple. Given everything you know about a problem, pick something that your gut says is flexible and good enough, but nothing more. Be concious of sacrificing flexibility, that’s how we get out of binds later on. The biggest risk we face as engineers is the risk of the unknown. Picking a prudent foundation, or a solution that minimizes the risk of the unknown, is the best we can do given the circumstances we are faced with.

Let’s examine the most egregious misapplication of premature optimization. As I stated earlier I believe this to be language choice. Choosing a programming language is almost never a premature optimization. Language choice is about many other things, but mostly it’s about picking the right tool for the job given the problem’s business context. Optimization, premature or otherwise, plays very little role here. The problem and business context define the criteria under which you should consider your decision.

Picking a prudent foundation is not premature optimization, even if 10,000 hater-programmers believe it be at first glance. Usually, the premature optimization crowd are speaking from a position of comfort. It is premature optimization if it uses anything they aren’t: (a) familiar with, or (b) comfortable with (no, these are not the same thing).

As engineers, one of the most important things we should be doing is discovering and promoting the prudent foundation for the problems we are faced with by making sound technology decisions.