“The key to project planning is to embrace the obvious fact that people don’t know, what they don’t know.”

Requirements and deadlines are the methodical drum beats engineers march to. This holds all the way from bridge building, to systems architecture to large network topology design. The more well defined the problem, the more predictable the performance. The machine like efficiency with which grand systematic projects are executed is both beautiful and awful.

“Inflexible project management is best reserved for generating mediocre fast food.”

All but the most trivial dynamic systems are unpredictable over an extended period of time. There’s nothing that grates my nerves as much as an absolutely rigid plan with an inflexible schedule, carefully orchestrated to execute a “known” solution. Why are people doing that job? Thinking, feeling, creative beings aren’t well matched to repetitive mindless tasks¹. For that job you want robots coordinating other robots. And in all but the poorest areas it’s not cost effective to have people performing tasks that machines are capable of doing.

Drowning in Waterfalls

It’s unfathomable that project managers continue to rely on fixed overlapping intervals for complex scheduling. Waterfall planning requires all dependent components be complete before follow on integration steps. Each element delay pushes back the entire project delivery. There are a range of popular alternatives to milestone planning, but they share common flawed assumptions. Beyond catchy names and micro milestones, I haven’t witnessed an advantage to replacing one orthodox rules based system with another.

Fluid Schedules and Iterative Model Driven Development

“Take all your expertise and stuff it… for the moment”

Experts are blinded by barriers assembled brick by brick through years of practice. We are all creatures of habit and favor the tools and solutions we know best over unfamiliar alternatives. And yet the environment is changing around us as fast as we can adapt (or faster).

If the system your team is designing and planning for has even the slightest bit of novelty, then iterative model driven development is a viable option to test initial designs and to better plan and understand development schedules.

The basis for MDD (model driven development) is rooted in stub and complete system tests which validate subtle changes in functional behavior.

The core idea is to fabricate the simplest possible system and element representation which mimics the desired behavior of a system design. You can think of this as model 0, or more specifically zero order system and element models. Immediate knowledge is gained about assumed bottlenecks and system level characteristics. This information feeds back into planning and design, which leads to refined models for the system and elements. Time can be allocated towards incremental improvement of individual element models, or the system backbone.²

Model enhancements are more predictable, yet less constrained. Incremental development of higher fidelity models allows the overall system to be tolerant of element delays.

Notes:

1. When I refer to repetitive tasks, I mean no disrespect to master craftsmen and artisans. Their work is far outside the bounds of mindless, I’d instead describe their work as mindful.
2. The system backbone is loosely constrained to be on the same order of complexity as an element. The balance between system backbone and elements is analogous to the roles of controllers and models in application design.

As I patiently waited, the bright warmth of the sun filled my truck’s cabin and lit up my face. No tinted windshield or visor could hold back the power of this brilliant behemoth. In a moment any work anxiety I harbored was banished. I wondered why can’t developing and leveraging software feel like the uncompromising embrace of the morning sun? What are the aspects of sunrise that lead to the emotional response I experienced?

What does it take to develop sunrise like software

In the remainder of the post, I’ll describe key aspects of sunrise that I believe developers can emulate in their work.

1. Trust and Reliability
   
   Rain or shine we know the sun remains with us. Even in the darkest of nights or amidst horrific tempests we can count on the sun to rise again.

   Non-critical software doesn’t require perfection or zero outages. It is of human making and inherits both our brilliance and beautiful flaws. Your work flow likely includes clever hacks around software instabilities or limitations, but for the most part it works as advertised. Exceptions include software forced on users (damned corporate policy) and parasitic fly by night or malware operations.

   In order to craft reliable software developers strive for internal and interface consistency whenever possible. This is achieved by far more elements than I can squeeze into a single list. A few best practices include avoiding replication of source, regularly reviewing or refactoring existing code, and extensive testing whether automated or by expert review. Social coding on company teams or in open source projects has its own set of customs and best practices
   

2. The Sun’s Power is Awe Inspiring
   
   Ancient cultures worshiped the sun for compelling reasons. It’s energy empowers the vast majority of life on our world.

   So too can software be potent. It can render life saving or breath taking visualizations and sift through incomprehensible data. Libraries enable developers to rapidly construct new powerful tools while building on existing infrastructure. If the software you’re crafting isn’t striving to achieve or help make possible the above, why are you building or maintaining it?
   

3. The brightest stars aren’t much without us
   
   There are billions and billions of stars, yet without planets capable of and actively supporting life, they’re not very interesting. So too must software have active users, maintainers, and developers else they lay dormant.

   Art may be crafted without an audience, but when nourished and enriched by adoring fans it grows into and becomes the foundation for culture. It is under the lens of repeated and diverse attention that good projects become great, and great projects become legend.
   

The major concerns for professionals is tool quality and stability. Will a given framework or platform pay off dividends for the time spent learning, maintaining, and mastering it? We all play the role of investor when it comes to choosing technology worth learning, and there’s never a wasted surplus of free time.

One mistake I keep repeating is struggling to maintain multiple small applications at the bleeding edge of a few attractive development stacks. It’s challenging to be aware of what’s in the latest release of Rails, NoSQL soup, or JavaScript’s framework of the day. That list doesn’t even consider the depth of domain specific utilities such as datamining or visualization.

Each programming language hosts thousands of utility libraries of which only a rare few grow into self sustaining communities or stable elements. Out of those “survivors”, only a handful are applicable to the type of work you’re doing right now.

Build ahead or behind the bleeding edge

There are two sure fire methods to hedge one’s bets on technology. Either build your own tools, or select proven tools based on historical quality and reliability.

The advantage of building tools yourself is having full control of updates and release cycles. There’s no driving force to jump to the latest and greatest because you dictate when new versions are ready for your products. The code is as reliable as your code review guidelines. In open source development there may be forks and community updates which are attractive, but there’s still no requirement to jump to a bleeding edge. Your team can maintain productivity and let evolution take its course, adopting attractive features when they’re both stable and broadly endorsed. In fact your team can experiment in community branches, and fold them into production when it best suits product, customer and market needs.

The other way to stay clear of edge effects is to choose stable and mature tools. There’s a good chance that c++ compilers, and java virtual machines will be around for some time to come. Embracing utilities which rely on these foundations is a safe bet.

In my professional experience I’ve been on both sides of the bleeding edge, by creating my own utilities, and adopting proven standards. Each path has its own merits and drawbacks, so take time deciding which strategy is right for your current project and task. Your clients and team will appreciate your careful thought and review.

While exploring a novel tool is almost never a waste of time, we are judged predominantly by our ability to produce, not our ability to learn. Part of team leadership is making objective choices, which aren’t always popular.

Regardless of your specific team role, there is a familiar pattern to breaking ground on a new program. Each time you create or join a fresh project it’s common to go through a ramp up phase which may last minutes or a few weeks depending on project maturity, complexity, and schedule.

During the learning phase it’s customary to understand the project goal(s), what’s already been accomplished, and what other sharp folks have done to address similar tasks (research). Then based on loose to well defined requirements, a good enough approach is executed and examined. For a given task successive satisfaction tests are applied by the individual, team and leadership until one of several conditions are met:

1. the task is judged complete
2. the task is handed over to someone else who can better execute
3. the task is determined to be too challenging, impractical, or ineffectual and is cancelled
4. the plug is pulled, and the project is cancelled

What are the outcomes of the above options? The first results in moderate success, the second occurs when leadership overestimates individual strength in a particular area, the third happens when a team is learning and isn’t afraid to change direction, and the final option is all too likely in large organizations where lower priority projects are killed off regularly.

Recipes vs Improvisation

The above case is generic, by the book, and is absolutely horse shit if you are building anything novel. The risk reduction strategy is a recipe for minimizing failure, not for succeeding brilliantly. There is no cookbook for creativity.

If you’re the type of person that relishes in well defined objectives and organized execution, you’ll embrace and adhere to strict recipes which result in predictable results of limited productivity. If you prefer stomaching huge risk and the unknown just for the chance at bringing a brilliant solution to life, then you’ll lean far more heavily towards improvisation. Real projects lie in the region between polar extremes, requiring adept skill to keep in harmony or purposefully out of balance.

Fight, Flight or Freeze

When your boss offers working unpaid overtime versus a bear wrestling match, you invariably choose the OT. Yet to the mind, stress induced from crunch time is no different electro chemically than a bear attack, except in degree. The good news is that we have a million or so years of evolutionary experience dealing with stress².

The human mind is hardwired to respond to imminent danger in one of a few ways, the obvious two being escaping a dangerous encounter or fighting for survival. There’s a third response not nearly as celebrated as the options above, that I call deer in the headlights. Sadly it’s all too common during crunch time, and it’s tell tale sign is freezing up and taking no productive action³.

The response is not the crunch time characteristic I’m interested in, but freezing up will curtail any required action. We survive stressful situations for a number of reasons, only one of which is important to information filtering:

• it was all in our head, aka false alarm
• we were lucky
• we took immediate and appropriate action based on essential information

I’ll wrap up this morning’s post by concentrating on that last bullet.

Super Human Filter

On a number of occasions I’ve revisited super human filters (plural), but within those posts I focus on social information filters⁴. The ability I’m about to describe is available to each of us, even when completely isolated from the hive mind we call the Internet.

The silver bullet to decision making during peak stress is our uncanny ability to filter out all nonessential information. Ben Horowitz keyed me into this after reading his post on peacetime and wartime CEOs. He discusses the operating mode of wartime CEOs as laser focused on a single objective, micromanaging anything that is essential to company survival. This state sounds exactly like extended crunch time to me.

As long as we’re stressed out we’re able to tune out distractions with unmatched efficiency, a necessity for execution. The threshold for novel but nonessential information is elevated based on environmental stress⁵.

How long is too long

The drawback is that during crunch time we’re far more likely to throw out the baby with the bathwater, allowing high quality information to fall to the floor and inhibiting future decision making and action. Crunch time is not the best tactic in all situations.

Experience teaches us when and how long to rely on crunch time’s laser beam focus and when it’s time to return to more creative modes of serendipitous attention. Experienced leaders know when to guide their team into creative growth phases or execution mode, providing an effective blend of tactics.

Notes:

1. Have you heard Curlers shout and watched them sweep? That’s a serious stress response
2. The timeline for evolutionary training is longer if you consider fear responses from ancestor species
3. Freezing up during stress: Been there, done that and lived to tell the tale. The remedy to the frozen death spiral is equal parts good friends and insane laughter
4. I’ve reused the term super human filters or mortal portals if I don’t mind flipping a nickel to Louis Gray. It has been an irresistible recurring theme on victus spiritus, explore past posts on social filtering if you’re so inclined
5. stress levels in order of severity:
   • boss yelling at you
   • psycho with a gun to your head
   • wife’s eye twitching stare for saying something inappropriate

Why is Dropbox more popular than other programs with similar functionality?

and the answer by Michael Wolfe:

Well, let’s take a step back and think about the sync problem and what the ideal solution for it would do:

There would be a folder.
You’d put your stuff in it.
It would sync.

They built that.

Why didn’t anyone else build that? I have no idea.

“But,” you may ask, “so much more you could do! What about task management, calendaring, customized dashboards, virtual white boarding. More than just folders and files!”

No, shut up. People don’t use that crap. They just want a folder. A folder that syncs.

“But,” you may say, “this is valuable data…certainly users will feel more comfortable tying their data to Windows Live, Apple Mobile Me, or a name they already know.”

No, shut up. Not a single person on Earth wakes up in the morning worried about deriving more value from their Windows Live login. People already trust folders. And Dropbox looks just like a folder. One that syncs.

“But,” you may say, “folders are so 1995. why not leverage the full power of the web? With HTML 5 you can drag and drop files, you can build intergalactic dashboards of stats showing how much storage you are using, you can publish your files as RSS feeds and tweets, and you can add your company logo!”

No, shut up. Most of the world doesn’t sit in front of their browser all day. If they do, it is IE 6 at work that they are not allowed to upgrade. Browsers suck for these kinds of things. Their stuff is already in folders. They just want a folder. That syncs.

That is what it does

Product Identity

The hardest part of early app design is determining what is essential to an application, and what is out of character or a distraction. In nearly all cases as early product designers and implementers we expend resources on features that are defining characteristics, yet we also add and maintain features we aren’t 100% passionate about because we believe they might be relevant. In effect our failure to make a hard decision results in watered down effort where it counts, and additional complexity and maintenance. I believe that our duty as early product designers is to relentlessly prune any superfluous features until only an irresistable base form remains.

There’s a related question of data capture and what to add to your document store. Here I believe that more is better. Grab every stat you can about how clients interact with your application. You can always decide to dump irrelevant data later, but you can’t retroactively add important data. Many modern databases are flexible allowing new values to be added as you go, but having access to information early will impact rapid decision making about resource allocation (ie everyone’s going hog wild about the Motherf**king Faces).

Icarus learned the hard way that gravity is a harsh mistress

Before you take on the world, know your blind spots

The higher you soar, the more damaging the fall due to catastrophe. Why allow a known risk to go unmitigated, namely one’s own shortcomings. Regardless of how far you progress up the success ladder, without first coming to terms with your weaknesses, all you’ll end up building is a bigger chute to the bottom. What can we do to prevent a flaw from being as tragic as Icarus’?

Recognize and embrace your faults

Attempting to fix all of one’s flaws is the ignorant labor of youth. Dissecting aspects of human nature that don’t fit an ideal self image is a fool’s errand. Strong measures once taken reduce the impact of personal liability, but they’re almost always reactions to symptoms. Is your midsection the result of gluttony? Diet and exercise are the cure, for a few years. Drink too much, abstain. Can’t resist licking envelope glue, there’s nothing on earth that can help you. The empty feeling of the addict is a deep psychological condition that even strict life changes fail to treat. Being human is learning to address our weakest aspects with compassion. We are the sum of all our inclinations and dreams, both benevolent and malicious.

The modern day startup equivalent to drone behavior are founders who blindly follow outside input. The major communication channels are customer feedback, investor direction, and other successful entrepreneurs. If customers knew precisely what they wanted they wouldn’t need you. If VCs knew what the next big thing was going to be and how to build it they would hire employees, not bet on creative leaders. Other entrepreneurs aren’t you and your team.  They have their own vision, identity and market perspective. 

This weekend I watched the rest of Dave McClure’s talk at Startup School about why not to do a startup. He mentions how much it sucks, family neglect, and failure. It’s funny how Dave speaks as if founders have a career choice*. If you’re founder kinda crazy, you’re never going to be satisfied as employee number 1+. A founder’s outlook and skill set can’t match the specialization required to be an alpha employee in the long term, they’re different animals. For the alpha employee, mastery of a given trade is how they express their autonomy. The founder does what is necessary to achieve a driving goal, but rarely has time to explore the nuances of particular crafts.

Seth Godin tags self motivated builders, leaders, and connectors as Lynchpins. It’s pretty clear that he holds these folks in high regard. Seth’s work reminds us that enthusiasm, self direction, and self responsibility are integral to the future health of the US economy. The jobs that don’t require independent thinking or specialized craftsmanship quickly sink to the floor in benefits and satisfaction. 

Identify and feed the source of your enthusiasm

It was time to revisit why I first began this blog, inspiration. How can one be inspired without close association to their own voice. Autonomy is inseparable from satisfaction and success. As a society we celebrate and reward authentic leadership. Autonomy is a welcome ally in desperate moments when faced with a decision to blindly follow, or determine a path forward.

Notes:
*= Orthogonal to the topic of autonomy, it’s not like there’s a huge hiring spree among US companies now. Survival is a potent motivator. There’s no security more real than providing a needed product or service to a group of steady customers. In a very real sense Americans are faced with the harsh law of nature, build or starve.