Java Jedi

The thoughts, experiences, and misadventures of real world Java developers.

Monday, May 23, 2005

Management Mind Tricks, Vol. 2: The "Nut Up Over the Tiniest Thing" Strategy

I had a boss once that had a brilliant strategy for artificially building something up to a group. He would pick the smallest little thing that was wrong about it and just completely go nuts over this insignificant aspect. For example, if he were describing a development tool, he would rant for 5 minutes over how much he hated the editor fonts. The perception by the unaware group is "Wow, he's really going nuts over this tiny little thing -- his standards must be super high!". Of course, what he was doing was hiding the major things that were really messed up by focusing on a little imperfection. If this is done with conviction, you can convince people that their own experience is lying to them. "I must suck if I think this tool is no good, because Mr. High Standards really loves it!".

This technique can be applied to tools, methodologies, and even people. This is also a devastating marketing trick, especially if you are advocating something that isn't your own product.

Friday, May 13, 2005

Anakin Dynamite

I guess with the new Star Wars release coming out it would only be natural to put Napoleon Dynamite with Star Wars to produce Anakin Dynamite


Thursday, May 12, 2005

"Okay" Defense Maneuver (Light Side)

This is a pattern that I've typically used most often when resolving conflicts with someone on the same level as myself. In situations where someone feels strongly about something but are saying such outlandish things (see the example below) it is sometimes in a Java Jedi's best interest to conserve energy, do it your way, and still provide for an "out" later after it is discovered you did indeed do it your way.

  • Name - "Okay" Defense Maneuver (Light Side Power)

  • Problem - Dealing with someone on a topic in which it would take more energy to convince them to agree with you than to just do it your way.

  • Context - Typical expressions of this problem is when people (project managers, owners of the company) who have no technical idea about the problemspace but still somehow manage to form an "informed" opinion they wish to defend to the death.

  • Forces - Political dynamics, team efficency, time utilization

  • Solution - The desired outcome is for the other person to believe that you're listening to him/her while still allowing you implement your own solution to the problem. To this end listen to the other person's ideas and only respond with some non-commital response such as "I see" and "okay". Implement the solution as you see fit. When asked later why you did your own thing while agreeing with the other person you simply comment that "I see" and "okay" means "I understand what you're saying" not "I agree with what you're saying". It's a win-win for everyone: you get to do it your way and the other person got listened to.

  • Example -

    You're in a design meeting covering some section of the software application you're building. One developer is adamant that the "Charade" pattern is the perfect answer to the problem. You, of course, know there is no "Charade" design pattern. After trying to explain this a few times you decide to implement this pattern for the conservation of energy for you and the team (and get out of this meeting sooner). For the rest of this specific discussion you simply reply with "okay" to all of the developer's continued monologe.

    You implement the solution using well understood design patterns. During a discussion or code review fully disclose that you've solved the problem your way. When the other developer/owner/project manager seems surprise that you did do after "agreeing" with him/her you can state that you simply meant you understood what they were saying - not agreeing.

  • Resulting Context - You've completed the maneuver: you've done it your way, already have a solution that works (so that makes the previous discussion moot), and you've conserved valuable energy for you and the team.

  • Rationale - Sometimes it just isn't worth it to "fight the fight". Maybe the other developer / owner / project manager just has no clue about the problem and explaining it to them so they'll understand would take more time than the project has.

  • Related Patterns -

  • Known Uses - The pattern was successfully used when working on a project that was producing a web application in the medical area. It came to the point where we needed to track how drugs were given out to patients. One owner has his own ideas how this should be managed even though he'd never written a line of Java code. This pattern was used to give him the warm fuzzy that he was "leading the team". After the implementation was done and tested and it was disclosed that another path had been chosen he seemed stunned his pearls of wisdom were ignored. When it was explained that "Okay." was simply an acknowlegement that it was understood what he was saying, not agreeing with it he had no ground for complaint since there was a working, tested system in place. It was simply not the way he thought best.

Wednesday, May 11, 2005

Development Planning, part 1

At my job, the devs are required to be more than just developers. We have to be process consultants, project managers, developers, testers, tech writers, trainers, and the plumber. I'm going to through the process of learning how to plan and estimate a project. Here's one of the tricks that I've picked up that our group is adopting.

One of the ideas put forth by Tom Peters ("The Mythical Man Month") is the "80 Hour Rule". To sum it up, any task must have a deliverable result within 80 hours. We have taken it one step further since if you have an 80 hour task doing RAD, you're not doing RAD. So we set it to be X and define X based on the size of the project. If this task cannot show a result, it can be broken down further. None of us had ever thought of this before, including people who had been doing project management for 15+ years. It's so simple I could weep. This also has a side benefit in that your estimating is already done. If you have 15 tasks for a project development cycle and you have defined X to be 10 hours and blammo, your 180 hour cycle estimate is done.

Software Project Patterns

Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. -- Christopher Alexander

I can say with some confidence that most people who might read this blog already know what software design patterns are. If not then I kindly provided a link for you to go figure it out. Go me. It recently dawned on me that in addition to software design problems there are living, breathing software project problems that occurred over and over again too. A typical reoccurring project problem might be a person on the project throwing out some whacked out idea for solving a problem and somehow getting the rest of the team to sign on to the idea even though it'll cause the project to hit the mountain - hard. Usually we'll address the problem each time is shows its ugly head. I think there are repeatable solutions to such problems that can we codified, written down, and shared amoung like-minded developers. Much like Management Mind Tricks, Volume 1 below that can used to overcome the problem of being right about something and having to overcome someone who has no real idea of the problem space there are numerous other patterns to discover and share.

Each of these patterns will have the following format and attributes ( thanks go out to Patterns and Software: Essential Concepts and Terminology for helping me define each):

  1. Name - A single word or short phrase to refer to the pattern

  2. Problem - A statement of the problem

  3. Context - The preconditions under which the problem and its solution seem to recur, and for which the solution is desirable.

  4. Forces - A description of the relevant forces and constraints and how they interact/conflict with one another and with goals we wish to achieve (perhaps with some indication of their priorities).

  5. Solution - Static relationships and dynamic rules describing how to realize the desired outcome.

  6. Example - One or more sample applications of the pattern which illustrate: a specific initial context; how the pattern is applied to, and transforms, that context; and the resulting context left in its wake.

  7. Resulting Context - The state or configuration of the system after the pattern has been applied, including the consequences (both good and bad) of applying the pattern, and other problems and patterns that may arise from the new context.

  8. Rationale - A justifying explanation of steps or rules in the pattern, and also of the pattern as a whole in terms of how and why it resolves its forces in a particular way to be in alignment with desired goals, principles, and philosophies.

  9. Related Patterns - The static and dynamic relationships between this pattern and others within the same pattern language or system. Related patterns often share common forces.

  10. Known Uses - Describes known occurrences of the pattern and its application within existing systems.

That should do for a start.

Management Mind Tricks, Volume 1

Over my career course as a consultant-type person, I've developed some patterns for dealing with irrational pointy-haired boss types and the technical sycophants that sometimes accompany them, and I've passed these on to friends for their own use. One has recently been used successfully and so I thought I'd document it here. Fortunately, the friend who used it also gave it the memorable name that patterns are supposed to have: "The 'Let Them Say Any Crazy Shit They Want' Mind Trick Pattern".

Here's how it works. If you disagree with someone on a technical point, and you know you are right and they are wrong (either from misunderstanding the problem, politics, underwear too tight, whatever), let them make whatever claims they want about their solution. The executor of the pattern calmly reminds them that his way is better for these calmly stated reasons. Let the arguer point to a phantom requirement, or phantom performance problem, or any other specious claim, and the executor remains calm and points out why his way is better. Repeat this pattern until everyone is saying that the executor's way is better. It takes quiet confidence, zen-like calm, and unshakable conviction, but it works. The recent application of this pattern by my friend (in conjunction with another pattern not of my devising) took 8 man-days but, in the end, they are doing it the right way.

This pattern only works if you are technically unassailable, and you have to concede if the arguer ever does make a salient point. However, the zen-like calm in which it is delivered still keeps lingering resentment over disagreements to a minimum. To be used sparingly in situations where nothing else seems to work and you are being asked to do something stupid for no good reason.