Power Divided By Complexity

In programming language and tool design, we often strive to maximize power / complexity. It's a universal formula in a sense. "Power" is generally meant in terms of utility (flexibility, conciseness, read-ability, etc.), not hardware usage.

I'm hesitant to apply it heavily to domain-specific apps because fitting the customer's needs is often the highest priority, not design simplicity because they won't pay you if it "almost" does what they want in order to greatly maximize issues that they don't care about in the shorter term.

For example, recently we had to rush to build an in-house web content management system. For complex office-politics reasons, two systems were created in parallel. Version "A" followed a cooky-cutter type approach where specific forms and slots were created for specific "kinds" of web pages. In other words, it hard-wired in content positions, sizes, and quantities to fit a fixed set of page "types".

I spearheaded version "B". I strove for flexibility, but also simplicity by using the analogy of stacked bricks for a given web-page (or section of a page). Each brick of a page segment can have a different format, such as having the image on the left, the middle, the right, etc. You can think of each brick as roughly corresponding to a paragraph, but the actual granularity depended on the formatting situation. Text formatting included indentation, hyperlinks, bullet items, etc. A page is then built of stacked bricks almost like Tetris (except the blocks are all rectangles). The thing is a single form (per "block" segment) could be use to build a wide variety of content page layouts. It also had "portlets" for separate columns or blocks, default block type, and HTML templating, but that's a side issue.

(Note that there are WYSIWYG JavaScript utilities that are usually used to dynamically build content pages in the industry, but due to the short notice, this wasn't available.)

Approach B maximized power / complexity because a single form replaced the dozen or so forms used by approach A. However, it was eventually rejected in favor of approach A because it was considered "too abstract" to easily learn. It seemed natural to me, but enough others felt it would require too much training. The target is a large number of not-so-technically-adept users. I think it will turn out more practical to have a smaller number of better-trained power users rather than let end users try to create content, but the jury is still out on that. There are too many things for newbies to mess up beside page layout issues and that will probably come back to byte the organization. Plus, I expect they'll need flexibility down the road. The project manager is technically naive with the belief they can predict most requirements up front (or doesn't care because future maintenance is somebody else's problem).

But in this case, the tool with the lower p/c ratio "won", at least in the short term. They wanted a glove for a specific hand, not a glove maker.

  -top

Dude, I don't know what sin you committed in your last life, but it must have been a doozy because in this life you obviously work in one of the inner circles of Hell.

It is indeed a Dilbertian organization (DilBert). I won't describe why here. Fortunately, a new CIO came on board and will hopefully organize things better. 2/3 of all organizations I ever worked or contracted for were Dilbertian. The 1/3 good ones were eventually bought up because they were successful and growing, and then ruined by MBA bean-counters. Dilbert is life and life is Dilbert. -t