Culture of Complexity

Several questions on Stack Overflow indicate a fundamental confusion about dynamic languages like Python.  It’s strange how people try make things way more complex than necessary.
There’s nothing like no power for 65+ hours when it’s hovering around 17°F (-8°C) that makes you think about which electrical appliance is most important
The “how do we protect our intellectual property?” question comes up from time to time because we’re using Python.  It also came up on Stack Overflow.  Here’s the approach we’re taking.
We have a couple of sales demo scenarios.  Currently, they’re packed into a Django “fixture” that rebuilds the database in the known configuration.  What if the sales folks need more?

It’s not like the lied maliciously.  They got caught up in the romance of web services and totally missed the use cases where business value was created.

Now we’ve got software that – viewed objectively – isn’t very close to what’s really useful.  What next?

If this project weren’t serious, it would be funny.

A reader notes that I omitted mentioning budgeting, metrics, personnel and documentation.  True enough.

Of these, three are management practices (budgeting, metrics and personnel.)  What’s important is that we need to be careful not to add management junk to Agile practices.  Not all legacy management practices are actually good ideas.  Some are just legacy.

We can very easily manage ourselves out of Agile.

I’m biased against Big Plan For Change™.  It’s embodied in PowerPoint presentations, project plans, farcical schedule and comical budgets.  Change could start out as a simple thing, but, for some reason, it has to start out as complex, overwhelming planning exercises.  With rooms full of consultants.  People like me.

I don’t think you should invest too much in a “plan for change”.  I think you have to just change.

Hoare’s Law:  Inside every big program is a small program struggling to get out.

Lott’s Corollary: Less code is better; no code is best.

“I can’t use [X] because of this small feature which I find objectionable.”  I have some other places where a sensible compromise was discarded in favor of an “all-or-nothing” strategy.  I don’t know why someone would take an all-or-nothing demand for the impossible.  But it does tell me how valuable the software is if they’d prefer none of it when they could have had some of it.

Give up.   First, no amount of “evidence” – like blog entries – will change their minds.  Second, PL/SQL isn’t a very good programming language.

Or, rewrite things in your preferred style and quit explaining to your peers how wrong they are.

I’ve run into this vague hand-wringing that lifts up “trust” among programmers.  They use the buzzword “scalability” to differentiate between a small team (where there are no trust issues) and enterprise-scale programming where “someone” doesn’t “play by the rules”.  What?

The paranoid claim that these “others” can’t be trusted, and specific defensive measures are required to protect “us” from the malfeasance of “them”.  They call it defensive programming and waste endless brain calories on writing pointless junk code.

It’s simpler than that.

While wrestling with XML and X12 (again) I found out about the strengths of lxml and ElementTree.  I also learned something even more important about the distinction between Plain Old Python Objects and having some other object model, but keeping Good Old Python Syntax.
Yes, it’s true.  I did get a question on how best to create an uber-meta-general-purpose many-to-many hierarchical association type.  I suggested they lay off the caffeine.
I think I finally understand why SOA has only a coincident relationship with reuse.
Why opt for a Service-Oriented Architecture?  “Better” seems vague an unsatisfying.  “Better than...” is a start.
A colleague dropped a line to chat about SOA.  The questions were interesting.
Another follow-up to Berkun’s ADD posting.  I find the “Keeping the Lights On” school of budget control to be particularly infuriating.
Check out Scott Berkun’s book (The Myths of Innovation ) and Blog .
Business analysis documentation should be very densely packed with information. However, there are two pieces of information to which I object.
I’ve been asked to address the “better” question many times. Here’s a scorecard for comparing two implementations.
See Sean McGrath’s post “AJAX and the hidden cost of ease of use ”, a reference to a more complete article in ITWorld.com . This isn’t the only hidden cost in a badly thought-out architecture.
I saw this quote the other day, and my jaw dropped. “I’d rather we have better control over our own destiny than relying on someone else” Seriously, they said “reuse be damned.”

A customer wants software to do [W]; it could be simple; it could be a replacement for an ultra-complex MS-Access application. In either case, large or small, the customer’s expectation is often murky. Our challenge is to understand what the customer wanted us to sell them in the first place. Right?

And where does education fit? It seems dumb to educate the customer. Shouldn’t we offer the customer what they wanted?

Why use an RDBMS in place of a simple message queue? We’re digging into the Holding a Hammer situation, and have three supporting arguments so far: Tomorrow’s Dollars Don’t Exist ™, it has All Those Features ™, and It’s Already Here ™.
Improving-NAO provides an interesting counterpoint on Over-Solving the Problem .
...everything centers on the database. Which is often A Bad Thing™.

See Information Week [link ] for a review of the new Office UI [link ]. Rather than trim Office down into usable, separate pieces, let’s add a new UI.

See Computer World [link ] for Frank Hayes’ take on this [link ]. You can embrace the change and suffer the cost of education, or you can reject the change and suffer the cost of support.

See Patricia Keefe’s column [link ] recently in Information Week . She reports on a Charlotte Observer story on a Tech Fiasco [link ].
The June DDJ [link ] has an article by Ed Nisley that repeats a common misstatement about Software Engineering. His thesis appears to be that perhaps this misstatement doesn’t or shouldn’t apply to software, but it’s hard to be sure. It could be irony, or it could be a repetition of the fantasy that software engineering is like “other” engineering.
In thinking about the value of the 20-Minute Solution [link ], the topic of business change came up. Sometimes, software developers don’t create value through software; they create value through disruptive thinking.
You can engage in the practice of programming for a number of reasons. Principally it’s software development. However, there’s pedagogy and hobby, also. And sometimes, all three get conflated.
Incipient(thoughts) forces me to think about bugs in “Whose bug is it anyway?” [link ]. How can we detect the rat-hole before following it to the dead-end?
See Five Reasons to Invest in Process Management (Intelligent Enterprise, March 1, 2006) [link ].
Some people have trouble stating the fundamental problem that their software solves. They bundle in irrelevancies of every stripe.
Huge effort, but what’s the value? How is this better than TreeMap?
Office has gotten so complex as to be about useless by ordinary people.
Who really needs to be in the loop?
Or, Why ROI is probably worthless.
Why roll your own HashMap to minimize entries, when you have a HashTree?
Allen Holub’s Column on “Requirements Gathering” is spot on.
The match is clumsy at best. This is a coincidence without too much real meaning.
Are there 7 deadly sins of Complexity?
Building Skills Content Management Culture of Complexity Data Structures and Algorithms Databases and Python DocBook Economics of Software Macintosh Methodology for Non-Programmers Open Source Projects Personal Web Toys Technology News Test Driven Reverse Engineering The Lure of XML Unit Testing in Python User Interface War Stories and Advice

Previous topic

S.Lott - Software Architect

Next topic

Python Business Rules Engine

This Page