Bill is truly in possession of an ActiveEngine toolkit. Read his material, learn and enjoy.

-- Albert Einstein

The significant investment we all have made in our systems is ephemeral, but not for the reasons that may be publicly acknowledged.  That is, the architecture we fail to select will become the black hole that all future investments and resources will be poured into, yet the reason that the anti-architecture platform was chosen quickly becomes irrelevant.  How many times have you heard "The business units are the experts.  They can model the domain without the developers."  Well, good authors may not be the best librarians.

One associate comes to mind when he quotes "We have added over 700 columns to the off-shelf product.  It's great - I get the screens that I want."  Little time is spent recollecting the long hours wasted because the database is completely de-normalized.

Agile can fail you here.  If you have put off important architecture decisions regarding the integrity and movement of data in your systems, you are in a precarious spot.  An O/RM will not help you here as there may be performance issues you need to consider first.  Yep, Big Up Front Design stuff.  It will help you out.  Keep it in your ActiveEngine toolkit.

Del Getz and Associates

It's not enough to identify objectives, FTE's and timetables. You have to focus your team like a unit. The wolf pack is natures most effective hunting unit, but in order to become that cohesive machine there are many activities that take place. "Respect your elders", "Corporate with the pack", "Teach the young" doesn't sound like cut throat competition within the team. It also doesn't really sound like SCRUM. The pack leader is there to silence the dissent that will destroy the pack. But the pack leader is the not only role.

The new team members are the future as all new projects will arise from their efforts. The leader has to discipline the team to enable the new team members to progress along the right path. Guarding territory can never conflict with getting new members ready for the hunt. The new team members will ask questions, voice opinions, bring new ideas to the group. Run with some of these ideas, as this will stretch the mind and team's muscle. Modeling ideas, quick throw away code, all these things that the group can play with while including the new team members will unlock some doors that have been shut tight for a while. Things will get solved in new ways.

Each team member will evolve their ActiveEngine as their skills and ambitions grow. When it comes time to hunt, the pack will be ready.

-- Einstein

Many applications have a life cycle, with some surprisingly long that leave you scratching your head saying "How the hell can that piece of crap ever be sold? Who could love this so much that they would keep it around anyway?" These applications become the vampire that returns to suck the life blood out of your company, as you pour more dollars into maintaining it, become dependent on the the few who have the skills to support it. It becomes a self perpetuating lie.

One such application is now in Sensei's cross hairs. This thing is the worst nightmare, where there is no source code. No source code! The application has a database that stores macro commands in de-normalized tables. There is a runtime interpreter - no not ANTLR - that must hit the database, read the tables, and generate the screen at application launch. For every person who logs into the application, this process must run. For 170 people. It sucks. It's a friggin' nightmare.

So now you are trapped, unless you take drastic action. And this will be hard, as there will be happy ignorant business units, spoiled by the fact that the consultants rapidly produced screens and reports without revealing that they added database attributes on the fly, created a custom solution for every single one of those 200 reports and screens, and have retained Visual Basic 6 as the platform for the runtime engine.

If there were code that could be read, it wouldn't be so bad. You see, there is a custom macro language that is used on the screen and report objects to do the work of implementing business logic. You can't debug, you can't set breakpoints. Despite this mess, the original progenitors of this nightmare are held in high regard as they created screens that people liked. Any one who doesn't believe that their work was great is reviled as an idiot. The icing on the cake is that the application performs the prospecting, billing and collections for the company.

You would think that with the awful truth looming on the horizon and the realization that the company is locked in with this awful solution, they would get rid of such a poor technology. This is where the product's weakness has created the barriers for its removal. You see, since this application is so vital to life of the company, no one wants to touch it. People's egos won't allow them to admit their mistakes. The weakness of the software's implementation - lack of coherent design patterns, legible source code, normalized database structures - is the strongest reason why is can not be eliminated, as no one can truly understand what this does. Being reminded of that fact is very uncomfortable for some of the stake holders.

Sensei has a plan. Like the end of Godfather 2 where Michael Corlione sends out the assassins to tie loose ends, expedient yet painful initiatives have been set in motion. The first act was to fire the consultants and fix their mess of a database with a new team comprised of in house talent augmented by a few good developer / mentors. The next step will be to reverse engineer the lexer / parser to divine the execution graph for all the objects and automate the documentation of the business logic. Stay tuned.

The same holds true for your core capabilities.  Outsourcing programming activities to third parties can be like paying someone to train for a marathon for you.  Unless you have involvement and control of the development cycle you will never have a working product worth supporting.  Sure, you can find Open Source products that will perform functions for you but you still have to put them through a test cycle, and the same holds true for third parties.  You have to test them as rigorously as well.  In the end the success of this test will depend on your specifications and ability to communicate to potential partners in development.

This brings us to the subject of testability and verification.  If you are going to have a development outfit produce something, how will you inspect it?  What if they are not on site, how do you inspect then?  Should you be on a mission critical application you need to sit in on the team meetings everyday you can get a feel for what is driving the productivity of the project.  Many firms don't like this, as it is disruptive to their processes but that's their issue to resolve.  Maybe if they are too ridged to accommodate that they may not be the right development partner for you.  Finally, you should insist on the test team conducting their tests at your facility, with you at each step.  Again your goal is to get a feel for the issues that arise - maybe they relate back to the arguments that you were privy to earlier during the development phase.

If you come through this with a third party and produce a successful launch then you can consider relaxing some of the oversight, but not by much.  Proximity only breeds a higher degree of honesty.  It should be easier for you to get a feel for timing of solution delivery as you will have worked with team members and be familiar with strengths and weaknesses.  You may be in a position to request that a certain individual work on a project because of a good history of delivery.  Who knows, maybe that person even practices ActiveEngine methods.

Streamlining your communication is simple: turn off email except for two times a day, write emails less, and refer people back to your goals and elucidate your objectives and tactics in context of those goals. Probably you could use your one pager. Copy and paste works great with email, so you have to type less. For team projects publish the objectives EVERYWHERE. And, do not use acronyms. English.

The next three concepts - the theory of necessary and sufficient, the 80 / 20 rule, and ignorance - are related. Necessary and sufficient are those things that meet the conditions, only those conditions set forth in your objectives. the corollary questions are: Do you need it, and does it do what it should? A little wisdom will be needed if you are concerned with building software, as sometimes necessary and sufficient can paint you into a corner. But in many cases it will keep you out of the valley of constant re-working your solutions. The 80/20 rule, or Pareto's Law, is the concept that only approximately 20% of any activity will produce 80% of your results. In other words, most of what we expend our energy on is not aligned with the productive acts that give you results. Both theories are enforced with that sheet of paper we talked about, as the activities you do should only be aligned with those goals. The one pager is the reference sheet for the ground rules regulating what you are working on, and in some cases how you do it. A state of "Ignorance" becomes applicable in that purposefully ignoring those actions, distractions, and musings that do not fall in the 20% category is a strength. If it ain't on the sheet of paper, it don't matter.

Finally, a calm submissive state of mind stems from discipline and consistency. Cesar Millan tames unruly dogs by walking them, everyday. This routine establishes order amongst the pack, and readies the dog to be formally trained. So, you need to"walk the project" and review those objectives, get the team members to recite them in their sleep. The benefits to these 5 concepts are clarity of thought, focused energy, and resolve. Imagine this: you bump into the CFO in lobby, and when asked what you are working on and your progress, you'll have already practiced the answer with the clear, succinctly selected words your whole team has using to describe the project. They will also echo your summary. Your streamlined approach will instill confidence when your superior does not struggle to understand what it is you are describing. You'll remain on task with the resolve to attain your goals. This will help you keep your job and advance. As promised, Sensei delivered the message: 5-4-3-2-1 you do it too.

But this was not the most brutal part. After the question and answer session finished, O-Sensei would then deliver his critique, which could cover any foible, any weird movement, tone of voice that occurred in your delivery. This was difficult to hear. Some times a senior would be selected to demonstrate the most basic technique, then receive unending criticism.

But one senior explained to ActiveEngine Sensei, who was left discouraged and afraid after many stinging reviews, that this was the best gift you could get from the seniors and O-Sensei.

"What an opportunity. You have people who think enough of you to ask questions, point out errors and give things for you to work on. The harsh style is to train your ego, because your ego just gets in the way."

Developers need to be shown things - they're the "Show me guys", but many fall into the "Show-me-no-don't-show-me" syndrome where their egos cloud their thoughts.  For those of you who want to get to the next level of performance and build your own ActiveEngine, check your ego barometer every now and then. This way you will open yourself to learning a lot more.

If you head over to ProjectManagement411.com Bob has started a conversation focused on how a Project Management Office (PMO) can assist with describing your domain of problems. This got me thinking about how difficult it can be to clearly define the goals of a domain in terms that all teams involved can understand.

I went to the archives at DotNetRocks, and listened to the Eric Evans interview concerning Domain Driven Design and Domain Specific Languages. Right off the bat Eric said, and I am paraphrasing, "Developers usually bring the the mindset to the table of 'how can I use web services or design patterns to solve this problem for my customer'. What is needed is better understanding of the customer's problems."

If you think about what he is saying, then Domain Specific Languages can only be produced after the development team are experts in the business unit's subject matter. Taken further, a Domain Specific Language, or even the size of the domain that the developers are attempting to model may need to be reduced drastically, as the customers business processes may not be mature enough for such finite detail. And consider the other end of the spectrum where the problem domain is very mature, and the development team is attempting to recreate the wheel just so that the problems fits the solution paradigm.

A practitioner of ActiveEngine will chose the course that aligns the interest of the clients first. You must have mastery of the client's subject matter FIRST, and be conversant in their language before you work your magic. Remember, if they don't understand you, they may pay much attention.

There are three levels to decision making that need to overcome. They are the intellectual level, the physical level, and the emotional level, and guess which one is the deciding factor? Emotional. And this level is the most difficult to overcome.

Programmers don't understand this as their emotions play out in different ways where passion is derived from creating elegant code. But this prevents them from moving the decision makers appropiately. If you state your case and point to real samples of timing, defects, and impact to other dependencies you may have a chance of convincing someone to make the changes you want. Use English to explain yourself and your arguments, and forget all the buzzwords you read on the blogs. Nobody important who signs your check cares about that jargon.
They do care about money. If you lose the intellectual battle, submit you case, and be ready to step in when they've been hit with a huge bill. Nothing crystallizes thoughts more than "I just lost out on an opportunity and we could have saved money." Be ready to move then. The situation is making the argument for you and you'll have to do less work as your arguments, if expressed appropriately, be even clearer.

Add the Art of Letting Bad Things Happen to your ActiveEngine toolkit. This new found patience will win you more in the long run.

All of that is shallow. No where was the term devotion used, or if it is, it's not too prevalent. "Do things with passion" or "Love what you do" are the slogans that are not associated with an ActiveEngine. Mobs are crowds with passion running high. Devotion is passion's filter, the drive for you to get up and go work when you have the flu, to review budgets when you rather be writing code. To constantly evaluate your tool kit and skills, add new techniques and discard bad habits when you are faced with your failures takes devotion. Passion may get you started, but devotion will help you cross the finish line, as it is the long burning fuel that steadily fires your engine.

In Budo, study of marshal arts centers on revelation through practice of basics. The higher or difficult routines are only achieved once the basics have become so ingrained they no longer have the same meaning, feel, or execution style when first introduced. This only arises from devotion. Study your craft, refine your ActiveEngine. Devotion with no .0, or .5.

Update:

Check out this article by Jaron Lanier - "Long Live Closed-Source Software! There's a reason the iPhone doesn't come with Linux." In it he refutes the idea that adopting Web 2.0 and Open Source methods would be good for scientific research. Good food for thought before you begin the New Year.

Here's what I'm doing today: ]]> http://activeengine.wordpress.com/2007/12/21/what-others-are-thinking/ Fri, 21 Dec 2007 16:08:01 +0000 ActiveEngine Sensei http://activeengine.wordpress.com/2007/12/21/what-others-are-thinking/ Great post over at ProjectManagement411.com. For those of us who bemoan the fact that management doesn't get IT, here is a glimmer of reprieve:

IT Systems Aren’t Evaluated by Takeover Artists? .

Management needs to understand that they are not drivers of a car; rather, they are airline pilots, where certain intricacies are vital for keeping the plane aloft. Ignore what the mechanics say, and you will crash and take many others with you - this includes shareholders as well.

Part of your preparation as a solution provider is to avoid conversations like the one's that Al and Wu have. Communication tools have been discussed here in earlier posts here . Developers fall down in this area, and many retreat to the corner of the Agilistas and pretend Design Patterns are like physics, but in the end if the client doesn't get you, you don't get your check. Richard Feynman, a truly brilliant man, always came back to the practical. When he presented problems, it was in terms all could understand. Practitioners of the ActiveEngine embrace the communication challenge as he did, and help everyone involved grow.

You should take the time to view each of these and share them with your team members, as it will jump start your interest in enhancing your development discipline. Work on your core toolkit and improve your ActiveEngine!

Enjoy:

Demystifying Design Patterns Part 1

Demystifying Design Patterns Part 2

Demystifying Design Patterns Part 3

Demystifying Design Patterns Part 4

Demystifying Design Patterns Part 5

Meanwhile, both India and China have made dramatic leaps in educating their middle classes - each comparable in size to the entire U.S. population. Compared to the U.S., China now produces eight times more scientists and engineers, while India puts out up to three times as many as the U.S. Additionally, given the affordability of their wages, China and India are now preferred destinations for increasing numbers of multinational high-tech corporations.

The premise of the documentary is that from 8th grade to high school graduation, student has 2 million minutes to prepare to enter the work force, be product, fight the good fight to win the prize, bring home the bacon and contribute to society.

How do we as developers, architects, project managers spend our time? Some may contend that expansion of knowledge is the best route, that continual acquisition of skill is the key to remaining on top. The way of Bushido is to constantly refine through the repetition of basics. The life of Josh Waitzkin supports the latter theory, as neural pathways of the grand masters are created through analysis and repetition. Can this be done in 1 million minutes? What ways are we learning? What are the essential components to good design, and are they emphasized enough?

Design patterns come to mind as a kata, or set of instructions that when practiced to a high degree lead to increased performance. Design patterns describe quickly how a problem has been solved, and set expectations as to what is in store for you when you open up the code and read what has been done. When done correctly, design patterns will gain back some of those precious minutes.

But back to China and India. Are we, the software and architect community, too cloistered in our blogs and Alt.Net enclaves to contribute to the reduction of the 2 million minutes? Are we even a part of that 2 million minutes? Think about it.

Execution in kingdom of nouns

After two times, Sally stopped nipping at Sensei. "Wow, that really works quickly", Sensei's mother says.

"It's easy to do, here's how, " and he showed her. The next time Sally started nipping, Sensei's mother repeated the maneuver many times and lo and behold, Sally learned to not bite.

There are some lessons to be learned here for those who wish to practice Agile, Test Driven Development and implement design patterns: you must learn good technique from good practitioners, then repeat, repeat, repeat while seeking feedback. There's no short cut to internalizing execution, and certainly no short cut to understanding when and why to apply design patterns. This begs the question for senior team members when do you make design decisions and what justification can you convey to junior team members concerning your choices?

Sometimes this can be very easy. The decorator pattern is a great example, as the justification answers the question of "I have many variations to accommodate in a billing process, and do not want a proliferation of classes or difficult logic to support all the exceptions." To make this connection between technical implementation with business requirements takes practice, and the articulation of the justifications is a great way to obtain fluency. Repetition and review and those key ingredients that help create a powerful ActiveEngine toolkit.

Anyway, The Code Slinger has two great posts on some work he has been doing with dymanic object instantiation and MSIL. True to the philosophy of ActiveEngine, he is asking why 5 times and proving that his ideas work. Check out his posts:

Dynamic Object Instantiation Part I
Dynamic Object Instantiation Part II

The business community is looking to solving problems, but they are not looking to you for help; rather, they want you to just make things work based on what they tell you the software should do. Because of that fact alone you may not be offering the value that will sustain your gigs, period. "Open to extension, but closed to modification" - who cares, because your customer base can't understand you what you mean.

ActiveEngine Sensei says head over to ProjectManagement411.com, and learn what the business community wants to hear and how to best communicate with them. You should read the series on value selling your projects, because you'll notice that NONE OF IT MENTIONS THAT MODIFICATIONS TO YOUR BUSINESS LAYER .DLL's WILL BE CHEAPER BECAUSE YOU USED THE DECORATOR PATTERN!!!! That's not on their minds, and hearing that from you maybe why they want to ship your job offshore. You need to learn how to measure value through their eyes.

ProjectManagement411 is focused on how the enterprise can become lean, how agility is going to become their ActiveEngine. Don't let this synergy pass you by. Concepts like Data Stewardship may make you snicker, but that is the way your stay will extended.

For those familiar with Bushido, there is a concept of an advanced study called Kenshu. This is a specially designated class where top students are taught to unlearn all bad habits, study the basic fundamentals in such detail that there learning abilities are transformed, enhanced to quickly acquire and adapt new skills at rapid speeds. A Kenshu student is distinguished by their ability to adapt new methods born from new understanding of old habits or from newly discovered techniques. The price to pay for such skills is the ability to endure intensive periods of repetition of movements, recital of rules, and study of martial arts technique.

A sensei is a teacher or mentor who selects and prepare students of Bushido or martial arts and the progenitor of the habits that will one day, hopefully, give rise an ActiveEngine. There is an old saying you do not find a sensei until that sensei has found you. If you want those skills you must be willing to submit to that process of repetition.

Technical teams need to be placed through the rigors of "forging steel", as the leader is the Sensei who will set their goals, who finds the avenues for growth, and who guides the team members to greater heights of productivity and capability. This is not philosophical farce such as "the sound of one hand clapping". No, it's the repetition of basics in attention to quality, or the reflection of things gone right and wrong on a project, and the drive become better. Then repeat, repeat, unlearn bad habits, repeat again.

The older teams members deserve to be honored, as their productivity can be jump-started by including their opinions, relying on their recalcitrance, asking them play the gadfly, or by allowing them to try something new. In the middle of a crisis, and there will be crisis, the older team members will provide balance. When Sensei is not present, hopefully they reflect an image of his teachings, and move others along.

You'll want all of their minds and efforts focused, and maybe you can build an even bigger, more productive ActiveEngine that is ready for the next challenge.

Why? That must be more inefficient since you're doing twice the amount of work. Why can't you just do what we listed on the specification we gave you? What about all that talk about necessary and sufficient?

Test Driven Development is often mis-understood, and that's unfortunate as the business community can greatly benefit from this approach to developing software solutions. Yes, there is additional programming required, but think of this effort as validation of a contract, and that contract is the set of criteria that you have given the developers. By following the proscribed approach, the developer will have thought through each facet of the code that leads to the fulfillment of the specification. No other code is written other than that which will fulfill passing a test. This greatly focuses on what is necessary and sufficient as nothing should be concentrated beyond the boundaries of the set of tests. The test are like that piece of paper with stick figures Al and Wu used to communicate to each other.

It must be noted that an advantage here is that when changes are made later on, as they always will be, the tests can be repeated again and it can be quickly determined if the alterations have broken other facets of the program. Luckily the execution of these tests can be automated, for as you can imagine you quickly end up with lots of tests.

Only after all tests are passing then the developer can perform enhancements as the tests will gage whether or not the program still functions as specified. Most programmers forget this part, as the artisan within can often subdue pragmatism, and some, but not all developers, will continue to will continue to develop code that will be used for the future, yet will not have hit the targets of the original specification. The tests will help re-enforce the boundaries. Who? Wu? No who, Wu! No Wu? Right here on the paper you idiot!! Yes, you should really yell like that at the programmers!

Heres a set of criteria, the basis of our program:

Process an increase in commission of sales for each customer:

• For customers that have been with our product line UltraSlim for 5 years or less, increase by 4%. All other UltraSlim customers increase by 6%.
• For customers that have been with our product line UltraSmart for 3 years or less, increase by 2.5%. All other UltrSmart customers increase by 3.5%
• Do not apply a commission for those customers who have been with either product line since 3rd quarter of the current sales year (calendar year based).

Seems like a lot? Consider this, if this is the criteria and the means for communicating you quickly begin moving in concert and hit those sweet spots of productivity. You'll find that you'll discover contradictory criteria that you may have supplied, and you'll both spot errors more quickly. That flow productivity and ideas will become your ActiveEngine for great software creation.

The next part in the series will discuss how these tests are validated, and will be technical in nature but of benefit to the business community, as when done properly they will communicate what the developers are doing with the code.

This is about the onerous task of updating 200 desktop computers with a technology that barely passes for worst practices from 1997. Yep, ten years of garbage code and retarded customizations, compounded by bad design and awful practices, 10 servers to update and 200 desktops to uninstall the old version and update with next version, the operative word being next.

For those not of the techie world, this can be a technician's nightmare. This complexity is increased when the software manufacturer pretends that they themselves have wisdom greater than the rest of software industry,shun standard practice, and create some unique yet "better" software update process. Processes that can not be controlled, that when followed would result in 200 computers updating automatically at once, and sentencing a corporate network to a speedy death.

Can you see the challenge? The task, create an update process that circumvents the software manufacturers, is automated with measurable outcomes, saves time, and executes successfully. The risk, if you fail the company can't invoice or collect the next month end close. Oh, and by the way, the sales force uses a pseudo workflow engine based on this mess as well. Better not disappoint that bunch of patient delicate artisans.

A team of heroes was assembled, people who had the strength of will to overcome the repeated failures and obstacles that such a nightmare offered. A team that turned on the ActiveEngine and fought like hell. For the most part, automation of software processes could be accomplished easily enough, but for a software push to operate successfully presupposes that all target desktops are in a state to be updated, and this is where the nightmare truly began. Picture this:

• 43 desktop computers could not be connected to remotely, meaning that files could not be copied from a central source using automation. So updates had to be processed by a technician logging directly into the machine.
• 15 desktop computers continued to execute update processes that prevent the crucial update from completing successfully.
• 27 computes had corrupted Windows Registries, meaning that network administrator ids could not install new or remove old software, period. This could be repaired but the duration of this task took 10 -15 minutes. If the repair process failed the computer could be rendered useless.

This last issue was the deal breaker, as it indicated that a computer was no longer under control. Scary thought. You see, you wouldn't find out that the Windows registry was corrupted until 2/3 of the install was completed. The figure above was ascertained after the entire set of 200 computers were updated. The prospect of failure heading into this mess was down right terrifying as what was not known could not be known.

Immediately diagnostics were performed on the registry. For non technical folks, this means that files containing more than 120,000 lines of code and security settings had to be examined. On a lucky break the starting point of the issue was ascertained, but this starting point was narrowed down to c. 20,000 lines. More comparisons to functioning registries were attempted, but the problem remained that comparisons were limited to eyeballing lines of registry keys. The support folks groaned, but offered their standard answer of "we'll have to compare this manually".

Unacceptable. That's acquiescing, not thinking.

The heroes researched and found SubinACL, a tool that creates text file of all registry keys and ACL's for those keys. The problem still existed that there was no way to compare text files from machine to machine. Not until the ActiveEngine kicked in and agile minds woke up, and a process to index the files - assign the same value for the same registry entry across all files - was created. Next, the files were imported into Access where the registry keys could be queried based on their ACL characteristics, eliminating any need for reading lines of registry dumps. 683 culprit lines were identified, 13 of these were unique. A text file with the new ACL's was created and SubInACL was executed with this file to apply to the security settings for every machine. Yes, one day's worth of programming eliminated weeks of work. The beauty of the brute force method was that if the settings were already correct, SubInACL would not apply the changes.

The code for this process will be discussed in a later post. It was a quick and dirty, actually really dirty, C# console app. Extensible enough to make quick changes and now subject to a re-write in hopes to create a flexible text file parser that will accept user defined fields that can be applied to the parsing process on the fly.

This inhibits your strategy. The goal is to win, go home, come back tomorrow and do it even faster the next time, yet with people talking over each other's heads there is no way you can start to run the race. Pitiful when you think about it.

One of the most memorable scenes from Deadwood involved conversations between slum lord Wu and evil anti-hero Al Swearengen. Neither could understand each other, and gesticulations added to additional confusion so they resorted to cartoon stick figures and and shouting matches until they communicated their meaning to each other. Al and Wu threw out all convention and stuck to what worked because they had no other choice. This clip shows the such a scene. Watch here.

You need to force your teams to do this. You're all speaking the same language, why can't you get it together. Start with nothing, don't accept "You use words I don't understand", and win the day with cartoon-ish stick figures telling the story.

An active mind needs this unfettered communication to truly create and execute. Consultants, drop your charts and grab a crayon. When you capture what is necessary and sufficient, then you can unleash all your talents to jump start your ActiveEngine of creativity.

(For those who are interested, the whole can be viewed here. Be warned, the language is foul.)

• "Keep them happy" - achieve the recipients goals at the expense of efficiency, maintainability and repeatably ("keep them happy");
• "Keep them safe" - complete tasks in a manner structured to handle variability.

That's the balancing act called your day. To complete this framework, compound juggling those goals with time constraints, emotional reticence disguised as rational, cogent arguments, and throw in some in-coherent email chains and a video conference. How do prioritize and get done should be done?

This blog is about keeping an agile active mind by creating an engine that is fueled by ideas, creativity. It's also about getting things done, and the great opportunity we have technology to do what's important, repeat that great success over and over, and shut off the background noise. Being smart and working less is really cool, and with the right technology you can produce great things. It's about creating an Active-Engine because it's the right thing to do.