Why Your Code is a One Way Time Machine October 19, 2009
Posted by ActiveEngine Sensei in ActiveEngine, Agile vs Waterfall, Mythology, Problem Solving, software economics.add a comment
What type of duress are you under? The unfortunate among us have been sentenced to slavery by our evil nemesis from the past. We all have this enemy, and at one time or another have succumbed to the enemy’s evil plot. The enemy from the past is YOU.
When you sit down to create a solution, you need to balance solving the problem with being able to maintain and implement changes to the logic you have selected. All logic changes, and there are very few times when you have the finite scope defined to be able to accommodate new ideas. ”Rewrite!” is the cry of many who have written good solutions that have solved the problem but more than likely are not very maintainable. ”Broken Cardinality” is the bane of all DBA’s, and this is very serious indeed. Sensei can’t help you with that – go beat your business analyst who didn’t drive home the rules of relational databases!
What Sensei will say is put your after you think you’ve solved your users problems in a two week sprint, step back and project into the future: will this code be readable; can you augment the logic without altering the methods; will you be happy with yourself at midnight trying to fix something? Addressing these concerns helps you maintain your solution.
The real challenge is to help yourself next year. The-future-you needs your help, but The-future-you will hate you if you misconstrue YAGNI in your design phase with avoid-refactoring-at-all-costs while you code. Forget the sprint. Putting something into a customers hands too soon masks the complexity of what you have done for them and undersells your true talents. They’ll be happier if you can quickly implement changes without impacting the existing environment. Congrat’s – The-future-you just bought a beer!
Dave Ward at Encosia Just Rocks! October 15, 2009
Posted by ActiveEngine Sensei in ActiveEngine, New Techniques, Problem Solving.Tags: jQuery
add a comment
If you are looking to have your mind just blown away at how hard we’ve been toiling with the tool set for .Net development, watch Dave Ward’s screencast on learning jQuery with FireBug. Forget Visual Studio and Intellisense, forget MS Ajax. Go find out how much time you have been wasting.
Dave has a brilliant series on jQuery and the beauty is he keeps it simple, but it is extremely effective. Mind-meld with his posts and find out why he is smarter than Spock! Take it on out with a jam.
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: ActiveEngine, bad software, communication, Data Stewardship, new thinking, paradigm
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.
This 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: ActiveEngine, bad software, communication, focus, Problem Solving
add a comment
Did you think you were constructing this:
but 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: ActiveEngine, Agile, Upfront Design, YuWantItWhen.com
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.
Brotherhood of the Wolf February 11, 2008
Posted by ActiveEngine Sensei in ActiveEngine, Business Processes, Coaching, Mythology, Problem Solving.Tags: ActiveEngine, On Boarding, Team Work
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.
The Art of Turning a Weak Excuse into a Strong Defense February 10, 2008
Posted by ActiveEngine Sensei in ActiveEngine, Problem Solving.Tags: ActiveEngine, gurus.
add a comment
A clever person solves a problem.
A wise person avoids it.
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.
Outsourcing Your ActiveEngine. January 28, 2008
Posted by ActiveEngine Sensei in ActiveEngine, Business Processes, Design Patterns, Problem Solving.Tags: AcgtiveEngine, outsourcing management, outsourcing pitfalls
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: ActiveEngine, Design Patterns, focused mind, goal setting
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.
Discipline is the Mind Liberator January 24, 2008
Posted by ActiveEngine Sensei in ActiveEngine, Coaching, Personal Development, Problem Solving.Tags: ActiveEngine, Ego, Liberation
add a comment
As a corollary to the post Ego is the Mind Killer, a practitioner of ActiveEngine principles will always seek the basics and routine to liberate the mind. Constraints are the best way to innovate, to turn the puzzle upside down, read the paragraph from end to beginning. Constraints force you to make a decision and take action, innovate further why attaining your goal.
Your skill built from years of hard work, trials of failure and above all the alacrity to achieve through struggle will shape your mind to solve problems more quickly. Having the discipline to face criticism when it comes head on tempers your talents like fine steal. Forgery of steel is violent, harsh, but what is born from pounding and fire endures.
Just because you solve something once, doesn’t mean you can not optimize later. Analysis paralysis delays validation of your skills. Fail early, regroup, then win. Maybe that doesn’t happen until the fifth time. Who cares – you’re on deadline so be assured you will be around to try again. When you deliver you actually get the freedom to experiment later on.

Subscribe to this Blog!