Now That’s an ActiveEngine – Agile Dissected and Skewered February 16, 2008Posted by ActiveEngine Sensei in ActiveEngine, Business Processes, Design Patterns, Problem Solving.
Tags: ActiveEngine, Agile, Upfront Design, YuWantItWhen.com
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, 2008Posted by ActiveEngine Sensei in ActiveEngine, Business Processes.
Tags: ActiveEngine, Bad design, ORM
add a comment
The significant problems we face cannot be solved by the same level of thinking that created them.
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, 2008Posted by ActiveEngine Sensei in ActiveEngine, Business Processes, Coaching, Mythology, Problem Solving.
Tags: ActiveEngine, On Boarding, Team Work
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, 2008Posted 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.