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?


ApprovaFlow: A Quick Primer On RavenDB December 15, 2011

Posted by ActiveEngine Sensei in .Net, .Net Development, ActiveEngine, Approvaflow, ASP.Net, Business Processes, JSON.Net, Open Source, RavenDB, Workflow.
Tags: , , , , ,

This post focuses on getting started with RavenDB, so we’ll set aside our focus on workflows for a bit.  It’s included in the ApprovaFlow series as it is an important part of the workflow framework we’re building.  To follow along you might want to get the source code.

RavenDB is a document database that provides a flexible means for storing object graphs.  As you’ll see a document database presents you with a different set of challenges than you are normally presented when using a traditional relational database.

The storage “unit” in RavenDB is a schema-less JSON document.  This takes the form of:  Because you are working with documents you now have the flexibility to define documents differently; that is, you can support variations to your data without have to re-craft your data model each time you want to add a new property to a class.  You can adopt a “star” pattern for SQL as depicted here, but querying can become difficult.  Raven excels in this situation and one such sweet spot is:

Dynamic Entities, such as user-customizable entities, entities with a large number of optional fields, etc. – Raven’s schema free nature means that you don’t have to fight a relational model to implement it.

Installing and Running RavenDB

The compiled binaries are easy to install.  Download the latest build and extract the files to a share.  Note that in order to run the console you are required to install Silverlight.  To start the server, navigate to the folder[] and double click “Start.cmd”.  You will see a screen similar to this one once the server is up and running:

The console will launch it self and will resemble this:

How To Start Developing

In Visual Studio, reference Raven with Raven.Client.Lightweight.  For CRUD operations and querying this will be all that you will need.

First you will need to connect to the document store.  It is recommended that you do this once per application.  That is accomplished with

var documentStore = new DocumentStore {Url = "http://localhost:8080"};

Procedures are carried out using the Unit of Work pattern, and in general you will be using these type of blocks:

using(var session = documentStore.OpenSession())
   //... Do some work

RavenDB will work with Plain Old C# Objects and only requires an Id property of type string.  An identity key is generated for Id during this session.  If were were to create multiple steps we would have identities created in succession.  A full discussion of the alternatives to the Id property is here.

Creating a document from your POCOs’ object graphs is very straight forward:

public class Person
    public string FirstName { get; set; }
public string LastName { get; set; }
public string Id { get; set; }
public int DepartmentId { get; set; }
    // ...

var person = new Person();

using(var session = documentStore.OpenSession())

Fetching a document can be accomplished in two manners:  by Id or with a LINQ query.  Here’s how to get a document by id:

string person = "Person/1";  //  Raven will have auto-generated a value for us.
using(var session = documentStore.OpenSession())
   var fetchedPerson = session.Load<Person>(personId);
   //Do some more work

You’ll note that there is no casting or conversion required as Raven will determine the object type and populate the properties for you.

There are naturally cases where you want to query for documents based on attributes other than the Id. Best practices guides that we should create static indexes on our documents as these will offer the best performance. RavenDB also has a dynamic index feature that learns from queries fired at the server and over time these dynamic indexes are memorialized.

For your first bout with RavenDB you can simply query the documents with LINQ.   The test code takes advantage of the dynamic feature.  Later you will want to create indexes based on how you most likely will retrieve the documents.  This is different that a traditional RDMS solution, where the data is optimized for querying.  A document database is NOT.

Continuing with our example of Person documents we would use:

int departmentId = 139;

using(var session = documentStore.OpenSession())
   var people = session.Query<Person>()
                          .Where(x => x.DepartmentId == departmentId)

In the source code for this post there are more examples of querying.

Debugging, Troubleshooting and Dealing with Frustration

Given that this is something new and an open source project you may find yourself searching for help and more guidelines.  One thing to avail yourself of while troubleshooting is the fact that RavenDB has REST interface and you can validate your assumptions – or worse, confirm your errors – by using curl from the command line.  For example, to create a document via http you issue:

curl -X POST http://localhost:8080/docs -d "{ FirstName: 'Bob', LastName: 'Smith', Address: '5 Elm St' }"

Each action that takes place on the RavenDB server is displayed in a log on the server console app.  Sensei had to resort to this technique when troubleshooting some issues when he first started.  This StackOverflow question details the travails.

Another area that threw Sensei for a loop at first was the nature of the RavenDB writing and maintaining indexes.  In short, indexing is a background process, and Raven is designed to be “eventually consistent”.  That means that there can be a latency between when a change is submitted, saved, and indexed in the repository so that it can be fetched via queries.  When running tests from NUnit this code did not operate as expected, yet the console reported that the document was created:


int posttestCount = session.Query<TeamMember>()

According to the documentation you can overcome this inconsistency by declaring that you are willing to wait until RavenDB has completed its current write operation.   This code will get you the expected results:

int posttestCount = session.Query<TeamMember>()
              .Customize(x => x.WaitForNonStaleResults())

Depending on the number of tests you write you may wish to run RavenDB in Embedded mode for faster results.  This might prove useful for automated testing and builds.  The source code provided in this post does NOT use embedded mode; rather, you have need your server running as this gives you the opportunity to inspect documents and acclimate yourself to the database.

There is much more that you can do with RavenDB, such as creating indexes across documents, assign security to individual documents, and much more.  This primer should be enough to get you started.  Next post we’ll see how RavenDB will fit into the ApprovaFlow framework.  Grab the source, play around and get ready for the next exciting episode.


Janga – A Validation Framework with a Fluent API September 26, 2010

Posted by ActiveEngine Sensei in .Net, ActiveEngine, Business Processes, C#, Design Patterns, Expression Trees, Fluent, LINQ, New Techniques, Problem Solving.
Tags: , , , , , ,
add a comment

Why can’t we  write code that read likes this:

bool passed = employee.Enforce()
                    .When("Age", Compares.IsGreaterThan, 45)
                    .When("Department", Compares.In, deptList)

One of the enduring challenges for software developers and business is to create abstractions that accurately represent concrete rules for business operations.  As opposed to operating like our tribal ancestors where you had to kill a goat, start a fire and listen to the blind boy tell the tale told for thousands of years, today we’d like to be able to read stories ourselves.  Hopefully the story that we read matches the reality of what we have implemented in our code.  Many nested if statements can quickly make verifying that the code matches the story very difficult.

A fluent validation API can assist with this.  Look at the code at the top of the post.  You can show that most people without having to get out the smelling salts.  For your fellow developers its creates a succinct way to express precisely what the logic is. They’ll love you for it.

Janga, a fluent validation framework for creating such an API.  There are three goals to be met here, and Janga fulfills these goals:

Goal 1 – Be able to chain “When” clauses together.  Each test – represented by the “When” clause – needs to chained together.

Goal 2 – Accept a test on any object property where the test criteria is defined in the form of x <= y at runtime.  The types of objects and their properties will not be known until runtime, so our framework must be able to analyze an object and construct a test against each property as it is presented.  This is NOT the specification pattern, where you define a delegates ahead of time.

Goal 3 –  Flexibly handle errors by either halting on the first error, or by proceeding with each test and logging each error as it is encountered.

The code Sensei will present here fulfills all of these goals and gives us the fluent magic we see in the sample at the top of this post.  Before we delve into the details, the sources for the ideas and explanations of Lambda Expressions, fluent apis, Expression trees,  should be acknowledged and applauded, because they got Sensei thinking along the right path:

Fluent Validation API

Roger Alsing – Fluent Argument Validation Specification

Raffaele Garofalo – How to write fluent interface with C# and Lambda.

Lambdas, Expression Trees, Delegates, Predicates

Expression Tree Basics – Charlie Calvert’s Community Blog

Marc Gravell – Code, code and more code.: Explaining Expression

Marc Gravell – Code, code and more code.: Express yourself

Implementing Dynamic Searching Using LINQ (check the section regarding dynamic expressions.)

Creating this api is a twisted cluster-wack of a zen puzzle.  The code for this solution consists of one class and three extension methods.  We’ll make use of generics, delegates and expression trees to evaluate our When clauses.  In the end we’ll see that with very little code we get a lot of mileage.  It took Sensei a long time to wrap his head around how to piece all of these things together, so hopefully the explanation will be clear.  Note that the solution has tests that demonstrate how to use the framework, so if you want to skip the madness and just try things out, go for it.

Goal 1:  Chaining When clauses together

To get the ball rolling, there is an extension method Ensure that will accept the object you wish to evaluate, encapsulate that object into a Validation class.

public static Validation<T> Enforce<T>(this T item, string argName,
    bool proceedOnFailure)
    return new Validation<T>(item, argName, proceedOnFailure);

Creating a chain of tests is accomplished with the Validation class and successive calls to the extension method When.  Validation encapsulates the object you wish to test.  In our examples that’s Employee.  Employee will be passed on to When, When executes a test and stores the results in Validation.  After the test, When returns Validation, and this creates the opportunity to execute another extension method.

public class Validation<T>

    public T Value { get; set; }
    public string ArgName { get; set; }
    public bool ProceedOnFailure { get; set; }
    public bool IsValid { get; set; }
    public IList<string> ErrorMessages { get; set; }

    public Validation(T value, string argName)


        this.ArgName = argName;
        this.Value = value;
        this.ProceedOnFailure = false;

        //  Set to valid in order to allow for different chaining of validations.
        //  Each validator will set value relative to failure or success.
        this.IsValid = true;
        this.ErrorMessages = new List<string>();


     public Validation(T value, string argName, bool proceedOnFailure)
        this.ArgName = argName;
        this.Value = value;
        this.ProceedOnFailure = proceedOnFailure;

        //  Set to valid in order to allow for different chaining of validations.
        //  Each validator will set value relative to failure or success.

        this.IsValid = true;
        this.ErrorMessages = new List<string>();

Signature of When (note that we return Validation):

public static Validation<T> When<T>(this Validation<T> item, string propertyName, Compare compareTo, object propertyValue)

Before we continue on with reviewing dynamic evaluation by the When clause, you could stop here and still have a useful mechanism for creating validation routines.  That is, you could create a extension method for each validation you want to perform.  One example could be:

public static Validation<Employee> LastNameContains(

        this Validation<Employee> employee, string compareValue)


    var result = employee.Value.LastName.Enforce("LastName",


    employee.IsValid = result.IsValid;



            .ForEach(x => employee.ErrorMessages.Add("LastName => " + x));

    return employee;


So instead of Ensure.When you will use Ensure.LastNameContains(“Smi”).  You will also have to create a new method for each condition.  This is still quite expressive and would go a long way to keeping things organized.  This would be more in the spirit of the specification pattern.

Goal 2:  Dynamically Evaluating Tests at Runtime

As stated, the “tests” are performed with extension method When.  When accepts the Validation object, along with propertyName and the propertyValue that you are testing.  The enum Compare determines the type of test to perform.  The comparisons are:

public enum Compare
    Equal = ExpressionType.Equal,
    NotEqual = ExpressionType.NotEqual,
    LessThan = ExpressionType.LessThan,
    GreaterThan = ExpressionType.GreaterThan,
    LessThanOrEqual = ExpressionType.LessThanOrEqual,
    GreaterThanOrEqual = ExpressionType.GreaterThanOrEqual,
    Contains = ExpressionType.TypeIs + 1,
    In = ExpressionType.TypeIs + 2

The magic of When stems from the use of Expression trees as delegates.  As defined on MSDN, an expression tree is:

Expression trees represent code in a tree-like data structure, where each node is an expression, for example, a method call or a binary operation such as x < y.

You can compile and run code represented by expression trees. This enables dynamic modification of executable code, the execution of LINQ queries in various databases, and the creation of dynamic queries.

This gives you the ability, at runtime, to dynamically evaluate an expression in the form of x = y, also referred to as a binary expression.  And in our case, we wish to evaluate:  Employee.Age = = 45.  The delegate takes care of presenting the type of the Expression and it’s components to the runtime engine.

Marc Gravell explains the difference between a delegate and an Expression as:

  • The delegate version (Func<int,int,bool>) is the belligerent manager; “I need you to give me a way to get from 2 integers to a bool; I don’t care how – when I’m ready, I’ll ask you – and you can tell me the answer”.
  • The expression version (Expr<Func<int,int,bool>>) is the dutiful analyst; “I need you to explain to me – if I gave you 2 integers, how would you go about giving me a bool?”
  • In standard programming, the managerial approach is optimal; the caller already knows how to do the job (i.e. has IL for the purpose). But the analytic approach is more flexible; the analyst reserves the right to simply follow the instructions “as is” (i.e. call Compile().Invoke(…)) – but with understanding comes power. Power to inspect the method followed; report on it; substitute portions; replace it completely with something demonstrably equivalent, etc…

.NET 3.5 allows us to create “evaluators” with Lambda Expressions compiled as delegates that will analyze an object type, the comparisons we can make, and the values we want to compare dynamically. It will then execute that tiny block of code. This is treating our code as a set of objects.  A graph representing this tree looks like so:

Each node on the tree is an Expression. Think of this as a “bucket” to hold a value, a property or an operation.  For the runtime engine to know what the type and parameters of the Expressions are, we create a delegate from the Lambda expression of that node.  In other words, we let the compiler know that we have an expression of type Employee and will evaluate whether Employee.Age is equal to 45.

To accomplish the magic at runtime, you need to set up “buckets” to hold Employee.Age or Employee.FirstName and their values with their respective type for evaluation.  Furthermore we want to be able to evaluate any type of binary expression, so our Expression will make use of generics and a tiny bit of reflection so that we will have code that “parses” the object and it’s properties dynamically.

The Extension Method When:

public static Validation<T> When<T>(this Validation<T>; item, string propertyName, Compare compareTo, object propertyValue)

Creating the delegate of the Lambda expression:

//  Determine type of parameter.  i.e. Employee
ParameterExpression parameter = Expression.Parameter(typeof(T), "x");

//  Property on the object  to compare to.  i.e. Employee.Age
Expression property = Expression.Property(parameter, propertyName);

//  The propertyValue to match.  i.e 45
Expression constant = Expression.Constant(propertyValue, propertyValue.GetType());

This takes care of the X and Y of the binary expression, but the next task is to create the comparison as an Expression as well:

Expression equality = CreateComparisonExpression<T>(property, compareTo, constant);

The type of comparison is determined by the enum Compare.  Once these steps are completed we convert the expression into a delegate with the statement:

var executeDelegate = predicate.Compile();

If you are worried about performance and the use of reflection, note that the use of static will greatly minimize this impact.  Basically you’ll take the performance hit on the first run but not on the subsequent runs.

Goal 3:  Error Reporting

For error reporting, Validation requires the name of the object with the property ArgName, and asks that you specify whether you wish to halt when there is an error.  This is accomplished with ProceedOnFailure.  An error log is created when you wish all tests to complete despite their respective results.  When you want to halt on the first error and throw an exception set the ProceedOnFailure to false.

Reporting the errors themselves takes place in each When clause, and this is implemented at the end of the When extension method.

//  Report Error handling
if(item.IsValid == false)
        item.ErrorMessages.Add("When " + item.ArgName + "."
            + propertyName + " " + compareTo.ToString()
            + " " + propertyValue + " failed.");
        throw new ArgumentException("When " + item.ArgName + "."
            + propertyName + " " + compareTo.ToString()
            + " " + propertyValue + " failed.");

Finally we need to return the Validation object so that we can chain another When operation

To recap, When is a dynamic filter where at runtime, code is evaluated and created on the fly to analyze and execute a tree representing code as an object.  The expression trees can be applied to any object and evaluate the object’s properties.  Holy snikes!!!  If that doesn’t scare you how ‘bout chaining When’s together by always returning a Validation object so that you continue to apply another extension method to it.  Twisted Zen mind torture indeed, since we have complicated looking code so that we can less complicated “business code”.

Here is the source code with unit tests.

Training the Young and Fluency July 28, 2010

Posted by ActiveEngine Sensei in ActiveEngine, Business Processes, Coaching, Fluent, Mythology, Personal Development.
Tags: , , , ,
1 comment so far

Repeat with Sensei, if you will, the Wolf Creedo:

The Wolf Credo:
Respect the elders
Teach the young
Cooperate with the pack
Play when you can
Hunt when you must
Rest in between
Share you affections
Voice your feelings
Leave your mark.*

What have you done to nurture your team?  Are you the resident Elvis, and if the newbies make the cut they’ll graduate from a Mort to be the next King, hand plucked by you from millions and millions of people?  Can I get a little ka-ra-te with that?

What makes you an Elvis, and are you a bloated drunk Elvis at the end, or the bad-ass version 1970 version who can jump start anything?  Elvis in 1970 practiced the Wolf Creedo.  Watch the documentory Elvis the Way It Is 2001, just the first half hour.  This short half hour will show you Elvis, after years of being away from touring, ready to return to touring again in attempts to re-start his career.  The first half hour of the movie focuses on the few weeks of rehearsals before the debut concert.  Elvis had a fluent, incredible means of communicating with his band members and back up singers.  With a glance, a gesture, a wink, a new song would spring up.  Maybe Elvis would say a quick word, hum a note, and suddenly a bass line would kick in, and not more than three beats later, the entire band and Elvis are playing a tune complete with improves.  While playing Little Sister, Elvis nods, and issues “Get Back” and off the group goes playing Get back from the Beatles.  Congruent would be best word to describe the synchronization that each member had.

Elvis nurtured that vibe.  They all keyed off of him, for to the band he was Elvis, not the King.  He lead by being a focal point, but not necessarily an ostentatious leader.  When you watch the practice sessions where Elvis worked on the orchestrations of each song it is clear that he could communicate what he wanted, and worked with his band members to produce the product he envisioned.

But in order to function like this unit, each member has to practice.  You, as pack leader, have to pick the scales, the arpeggios, the rudiments that you want to be second nature so that your team, the young ones and old warriors can produce what you want, fluently.

*Credit:  Del Getz and Associates

Chang-chang-a-ching-changa-langa-langa: Why Your User Community is Fluent in English and You Are Not the King February 6, 2010

Posted by ActiveEngine Sensei in .Net, ActiveEngine, Business Processes, Coaching, Fluent, Problem Solving, software economics.
Tags: , , , , , ,
1 comment so far

Get ready for the sound of one hand clapping, but first, fire off the song as it get’s your head straight.

Some of you want to be Elvis too much.  Sensei’s going to tell you a story so you know what he’s talking about.  You see, users of your apps  are waaaay smarter than you, and spend more time in their fields than you ever hope to do.   You need a little love.  It’s called fluent interaction.  Fluent. Interaction.  Lord have mercy.

Process mapping helps, but in the end that takes you to overly scientific abstractions, and while user stories help some they, too, stray with you as the sole author.  You in the chair, just the important details from the user, but mostly you.  Should you consider yourself not Mort but an Elvis, you may want to ask yourself what Elvis you want to be:

Kick-ass Karate Elvis
Drug Ridden Elvis Wanna Be

Back to the story.  Last episode, in a spate of productivity and a dose of SQL-NoSQL fever, Sensei created a slim document management solution that can be quickly applied to an existing framework with minimal impact to database schema and code base.  Sitting around the conference room table the comment arose from Annie, the project lead from the Sales group:

“Why do I have to save a commission record first before I can attach a document?  That interrupts my flow.  I want to put in everything that I want and save, period.  No dialog box thingy prompting to save first, come back and do something else.  Why can’t we just do it”

Long silence.  The sound of one hand clapping.

One of Sensei’s report-to’s jumped in:  “Because in order to associate the document to the commission you have to save that commission first in the database, then take the id from the record and associate it document.  This allows you to retrieve it later on.”

Annie:  So.  Can’t that just happen behind the scenes?  If it’s two steps the sales gal won’t do it.  She’s got calls to make.

Ssensei drifted out in research land, or as normal people call it, he spaced out for a bit.  NetFlix sprang to mind, iPhone too, where you delete, it does it, but you can bring it back.  Take the confirmation response out of the equation.  Give the user a chance to undo their mess, but don’t get in their way.  It’s fun to pretend to be the King, but what a wake up slap.  The technology was right, but the user was seeing the benefit because “putting the stuff in was too clunky”.  Sensei went and did want Annie wanted.  Annie thinks its great.  Good technology made better by the user, not the King.

Fluent.  Interaction.  Lord have mercy.  You see, Annie’s right and user stories, UML and other brain death would never capture the essense of her perspective, particularly after she used the software.  Yeah, soft deletes are great theory, but you are not thinking like a user.  In order to be a better King, you gotta give the concert they want to hear.  You have to know that the fans have created you, have shaped your persona.  You have to know your fans, almost be them.

Elvis had a come back concert in 1968 but it almost didn’t happen as there was a huge fight with NBC.  The network insisted that the show would be like a Bing Crosby special given that the air date was during the Christmas holiday season.  Elvis wanted an intimate environment where he could perform up close, live with his fans.  He thrived off of close contact with his fans.  Know your audience.  Elvis was right, and it helped re-launch his singing career and revive his legend.  It was one of his best performances.  For the fans.

You need to listen to your users.  Spend the time to hone your craft, but work even harder to make them fans.  What do they need?  Is the concert for them or for you?  Are you learning just to be smart or for their benefit?  Fluent solutions require interaction with the fans.  Thank you.  Thank you very much.

The Economics of Protecting the Red Shirts July 29, 2009

Posted by ActiveEngine Sensei in .Net Development, ActiveEngine, Business Processes, Coaching, Design Patterns, Mythology, Personal Development, Problem Solving, software economics.
Tags: , , , , ,

Recently I came across this post from a fellow lamenting the lack of interest on the part of .Net developers in architecture solutions such as IoC, Dependency Injection, ORMs, and the like.  800px-KirkSlapsSelfThis stood out in stark contrast to Java developers who this person interviewed, who either were conversant with the technology or were interested enough to pursue informing themselves further.  Some call this the result of Drag -n -Drop design as laid out in a post  by Greg Young, a Microsoft MVP and .Net developer who has specialized in high performance applications.  Greg maintains in his post Java vs. .Net Developers that drag and drop is mis applied and there needs to be an greater effort the isolate the cases where it is mis used.  This practice has arisen, he maintains, from poor training and lack of awareness of other development platforms. (more…)

Revenge of the Fallen July 21, 2009

Posted by ActiveEngine Sensei in ActiveEngine, Agile, Agile vs Waterfall, Business Processes, Problem Solving.
Tags: , , , ,
add a comment

Did you think you were constructing this:  300px-MovieOptimusPrime_promorender2but you were actually delivering this instead: (more…)

Now That’s an ActiveEngine – Agile Dissected and Skewered February 16, 2008

Posted by ActiveEngine Sensei in ActiveEngine, Business Processes, Design Patterns, Problem Solving.
Tags: , , ,

Head over to Bill Miller’s blog to read his great post on Agile on and applying the appropriate problem solving techniques to business processes. Bill very decisively lays out the case for NOT using Agile as a tool for solving problems; rather, you should use logic, analysis, and experience which can only be come with time. No shortcuts.

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

Bragging Rights February 13, 2008

Posted by ActiveEngine Sensei in ActiveEngine, Business Processes.
Tags: , ,
add a comment

The significant problems we face cannot be solved by the same level of thinking that created them.

— 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.

Brotherhood of the Wolf February 11, 2008

Posted by ActiveEngine Sensei in ActiveEngine, Business Processes, Coaching, Mythology, Problem Solving.
Tags: , ,

The Wolf Credo:
Respect the elders
Teach the young
Cooperate with the pack
Play when you can
Hunt when you must
Rest in between
Share you affections
Voice your feelings
Leave your mark.

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.

%d bloggers like this: