Advertisements
jump to navigation

The Speed of Thought April 17, 2013

Posted by ActiveEngine Sensei in ActiveEngine, Approvaflow, Business Processes, Coaching, Fluent, Mythology, Personal Development, Problem Solving.
Tags: , , , , , , , ,
add a comment

faradaypennytwinsOf late, Sensei needs to keep a clear head.  That has meant learning to segment ideas and really, really, really focus on streamlined features.  This is hard.  Not because Sensei has a plethora of great ideas.  That would be a nice problem to have.  Many times in software development you end up this guy:

This is the state where you have things you want to accomplish, yet even when you pair things down to the “essential”, other essential, critical factors must be taken into consideration before you create a mess.  This is life calling, and that string which suspends that giant sword that you noticed hovering over your head is about to snap.  There is a good chance that you need more discipline, better execution tactics, far better honed chops, you name the metaphor.  Sensei has been at this game for over 22 years, and still the speed that thought takes to become reality is way too slow.

With great sarcasm you can remind your self that some of the best work lays ahead, but the reality is that you still need to fight to be fluent, you have to claw your way to a Zen state of mind / no-mind.  So chose, the art of bushido or the art of BS.  Or maybe work smarter and enjoy life.

Before Sensei leaves you, ponder this:  does “being done” mean that you’ve dropped off a product but have to get on the phone in order to make changes, and maybe now that you are struggling why couldn’t you figure out to take time when it was more critical to be fluent with your productivity?

 

Advertisements

Getting to 11 February 13, 2010

Posted by ActiveEngine Sensei in ActiveEngine, Fluent, New Techniques, Problem Solving, software economics.
Tags: , , , , , , ,
add a comment

In the past Sensei has written insane tomes regarding time travel and how your best intentions really get you no where. The story today is about getting to 11, which as Nigel says is one more than ten, putting you over the top.  Consider for a moment the times that you really think you’re like this guy to the right.  Yep, you think you have a Martin Fowler sized audience when you are coding.  The scientists of the future will study my code and say “Here, this is the start of the great insight.  How interesting.”  In reality you are like Spinal Tap, unaware of how absurd you can be.  Code too complex, but it goes to 11!   Most blokes keep it at 10, but then you need to put it over the top take it up a notch.  That extra notch.  That’s 11.

Here’s a thought – what about 6?  Is it viable?  Can you be flexible by doing a 6, just good enough to not paint yourself into a corner?  “Perfection is a process, viable is an end state.”  As a developer you may not be able to judge what 6 is.  If you’re in tune with your fan base you’ll know but that can only come from wisdom born out of great mistakes.   For those of you who study Budo you may recall the concept of short and long and how relative scale can shift your advantage.  Your opponent may have a sword and you only a dagger.  Short and long makes a big difference, but you can alter that equation with small maneuver.  Once you’re inside and beyond the sword’s curring range you have the advantage, as your dagger is now long enough to finish the skirmish.  Change the scale.

Years back Sensei was given the task of reducing shelf space utilized by paper by 25%.  The CFO arrived at this goal via scientific method.  It was scientific since at Sensei’s company if you don’t do what the CFO said it is axiomatic that you were in deep doo-doo.  Laws of hierarchy and all.  Now imagine rooms filled with documents related to contractors, account-receiveables, human resources, legal contracts, project management etc.  Yah, DISPARATE is the word.  Not meta data, just a meta-mess.

Now in the best of all worlds where you need to get to 11, you would have time to survey all document types and refine each attribute set before you design your system for document categorization.  This foundation becomes your data model in a database and many would claim that you should a create data table per document type to house the varying number of attributes. But you have 2 million sheets of paper to scan and in 12 months re-construction at your offices begin so you need to be able to walk into a room and quickly categorize all documents, throw them into boxes, scan them, and automatically assign the meta data to the document and store the thing.  Oh, and if you miss a document type or need more attributes you don’t want to go back to your database, add or modify a table, re-gen your data access layer, add the attribute to your screen all before your adjust your categorization.  And remember, you need to ship out 80 to 100 boxes every 2 weeks so you need to keep the data entry flowing.  Finally, you are told that some projects can have up to 50 different types of documents, but no one is sure to what degree the project documentation is complete so the number of document types per project is not known and NOBODY HAS THE TIME TO GO THROUGH THE SHELVES AND CREATE DOCUMENT TYPES BEFORE ANY DATA ENTRY IS POSSIBLE!

Play the song, ’cause it adds to the excitement!!

Several key decisions solved this mess, and the solution was simple enough that temps could walk into a room categorize and pack documents into boxes for scanning.  The error rate ranged between 1 – 5% per department.  These were not solutions cranked up to 11, they were 6’s:

  • No change to database schema or screens will be made, ever.  A document was modeled with four tables with a base Document table, Document- Type table, Document-Attribute table that contained all attributes per Document-Type and finally a Document-Attribute-Value table where the meta data was stored.  This way each Document-Type could be be created with simple data entry.  One data entry screen that could create data controls on the fly per attribute type developed.
  • Each document shall have a bar-coded coversheet.  Nothing gets scanned without meta data.  EVV-ARR.
  • Import data from existing systems. The meta data for your documents resides in many of your accounting, job cost, and budget systems.  Once document types are known, dumping data from accounts receivable and / or accounts payable allows your to assemble thousands of cover-sheets for all invoices.  Quite literally you create a stack of paper for all possible types of invoices for all accounts, walk into a room, pull documents of the shelf, attach coversheets, and keep the sheets you didn’t use.  Now, since the unused sheets have a bar-code, run these through you bar-code reader and create delete records for what you didn’t use.  Now you have a complete accurate manifest of what was on the shelf and what was packed away.  When the scanned images come back you can inspect them against the manifest.
  • People can work better with paper.  As stated in the last bullet point, creating all possible types of document coversheets per account or project and printing them allows you to quickly categorize all documents.  With minimal or no data entry and a stack of coversheets, anyone now can go through shelves and associate the coversheets with the appropriate documents.  In other words, the subject matter experts have a tangible, traceable system that they can hand off and supervise someone who can do the grunt work.  Not sure where you finished with your categorization?  Just look at your stack of coversheets.  Want to inspect accuracy, grab a document and compare it to the categories printed on the coversheet.

What?  Process management with paper ?  That sucks!  No it really doesn’t.  You see, a 6 to you really is an eleventy-one for your user community who is really busy.  Yep, you have to be smart with your database design by focusing on one key area and that’s it.  The rest  of the effort is imports with SSIS packages, CSV files, and printed coversheets.  But it’s easy for the users to use paper, and that keeps a flow going.  2 million sheets of paper scanned in a year.  Maybe a 6 isn’t all that bad after all.

Faith – The Time is Now Again July 18, 2009

Posted by ActiveEngine Sensei in ActiveEngine, Coaching, Mythology, Personal Development.
Tags: , , , , , , , , , ,
add a comment

wolf-1

Ceiling unlimited
World so wide
Turn and turn again

Feeling unlimited
Still unsatisfied
Changes never end

Winding like an ancient river
The time is now again

Hope is like an ancient river
The time is now again

Neil Peart

 

 

Indulge, play the song, drink in the message and go hug your kids, embrace your family, be thankful for your friends, team members, co-workers.

There is so many new things on the horizon.  For those of us who are lucky enough to practice this technical craft called programming, we can be stymied by all the possiblities, the arguments and skirmishes.  These de-rail you.  Build a fortress against the distractions and ignore your fear of change by embracing the challenge of good arguments.  It’s all a chance for you to improve.

When you arrive at work think of what ways you can engage with others.  Can you practice your techniques in a better way?  Recite the Wolf Creedo and end an argument.  Better yet, start a new one in jest and revel in the ideas.  Bang out some code and fight for the day.  What new things can you add to your team’s arsenal if you inspire someone else?  Are you leading or are you a suit sitting in a chair?  Would someone ask you for help or think that you’re too involved in your own head to deign to talk to them?  Have you built an empire above you or below you?  Is your legacy more important than what you have truly done?

Okay, so you’re code was awful – but did someone else still benefit?  Was your code perfect but never used?  Was your ego hurt yet your company still profitable, keeping families fed?  Did your mistakes help others learn?

What matters is that you engage.  Most times it will be painful.  Developers need serenity to produce but I’m telling you man you’re lucky if you have it.  Life is full of the distractions and once you conquer them, you’ll find greater strength and battle hardened capability.  Work at it. Revel in it, share it.  Be grateful and humble.  Win and go home to the ones you love.  Technology is great, but you as a friend, mother, father, co-worker, neighbor, dude in line at Starbucks or grandma at church are even greater.

 

 

It’s Not What You Kenshu November 20, 2007

Posted by ActiveEngine Sensei in ActiveEngine, Coaching, Mythology, Personal Development, Problem Solving.
Tags: , , , ,
add a comment

Steel is forged, not uncovered, and forging steel is a violet process, but the end yields a magnificent tool. An ActiveEngine is not born, it’s made from disciplined process of training, learning, relearning and unlearning.

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.

%d bloggers like this: