jump to navigation

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: , , , , ,
2 comments

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: , , ,
2 comments

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: , ,
2 comments

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.

Outsourcing Your ActiveEngine. January 28, 2008

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

First of all, never, ever look for third party tools will magically implement your core, proprietary processes.  If your processes differentiate you from your competition, then by definition you will not find them boxed up in a software package.  You want an AR system, go buy one, as AR will no give competitive advantages as it just needs to function appropriately so you collect the bills.

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.

5 Concepts in 4 Paragraphs with 3 Reasons 2 use 1 ActiveEngine Method January 26, 2008

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

What is Sensei saying? With a title like that you should go to the next blog. NOOO!! This is a challenge to train your mind to use an ActiveEngine method. Why? Because you’ll find the productivity you’ll experience will be liberating. The ActiveEngine method is to state your objectives on 1 piece of paper, in English, with no acronyms, and read it everyday. It may seem underwhelming and obvious but it is rarely done. In the technical fields it is rarer, as quick and sharp thinks many times lack the discipline to keep things clear. So before we run out of paragraphs we better introduce the concepts otherwise Sensei won’t pull this stunt off. The big five are: streamlined communications, the theory of necessary and sufficient, the 80/20 rule, ignorance, and Cesar’s theory of the calm submissive mind.

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.

That’s The Cool Stuff We’ll Be Doing on the Mission Together January 14, 2008

Posted by ActiveEngine Sensei in ActiveEngine, Business Processes, Problem Solving.
Tags: , , ,
2 comments

“The greatest challenge to any thinker is stating the problem in a way that will allow a solution.” – Bertrand Russell

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.

The Art of Letting Bad Things Happen January 10, 2008

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

Coders love to improve things and sometimes can’t understand why a company would want to enhance or replace a “bad” process. Here’s some advice on being impatient with lack of change: don’t be impatient with a lack of change. When you rail against process owners they’ll think you think their stupid; when you flail at convincing someone of their inept ways and how extensiblity will save them money, you’ll stutter, sound like a techie idiot, and will be ignored.

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.

Web 3.0 at ActiveEngine Will Be About Devotion in 2008 December 30, 2007

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

Web 2.0 was all about relationships – the social network. Passion is also another term that is bantered about a lot in regards to the efforts of start ups and the new revolution that 2.0 was supposed to bring about. Has passion for social networks produced anything other than the ephemeral? After all, Facebook, too, will present you with ads.

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.