War Stories and Advice

Spent several painful days chasing the “Connection Reset by Peer” error.  I think I figured out what causes it.  And why I don’t need to care.
After a bunch of steps involving a bunch of parties, we have 60Mb of .zip files.  What now?
There are two candidate locations on the file system for application components.  One location is Python’s site-packages directory.  The other location is it’s own /opt/someApp directory.
The question of Web-Based Member Management solutions.
Recently, I talked with some folks at a small not-for-profit (“501(c)”) organization.  They keep trying to grow the web presence,  but they’re using a Web 1.0 model.  It isn’t working well.  Here are some suggestions.
I love the rhetorical technique of the false dichotomy.  It makes everything so simple, neat and wrong.  Here are some more that I’ve collected.
On PBS.ORG, Cringley provides a not-very true piece called The Truth About IT Consultants.
I’ve seen another abuse of the use case technique.  I think I have the start of a taxonomy of use case abuses.
Some argumentation techniques that effectively prevent progress.
TC writes “We consume a significant portion of the overall contract generating a functional specification whose sole use is to serve as the outline for the acceptance test.”.  And follows with the observation “changing course will require re-education at a level not seen since the Red Guard in the 60s and 70s.”  What to do?

A client told us “you did what the contract said, but you didn’t solve our problem.”  Our well-worn waterfall approach doesn’t seem to meet the client’s needs.  What to do?

The real problem with getting away from the waterfall model is the question of risk.  What do we do to mitigate risk?  If we don’t spend a huge amount of time up front analyzing and defining and clarifying everything, how will we manage all the things that could possibly go wrong?

I think I understand what a passive-aggressive response is, and I think I’ve seen yet another manifestation.  Maybe I’m not enough of a “people person”, or it could just be that they’re intentionally uncommunicative. Regardless of any (possibly inappropriate) labels, some developers have an agenda, won’t share it, and seem unproductive.  What to do?
I have very strong opinions on the value of triggers and stored procedures.  But the question was in the context of referential integrity declarations.  Wait, what?  When is RI a discretionary part of a data model?
It was a crisis: get this to “work”, they said.  But, sadly, it was really hard to define “working”.
Dr. Dobb’s has an article by Deirdre Blake, in which she interviewed Karl Wiegers on the subject of “Requirements”.  It’s a big topic, and well worth considerable study.  The first part of the article suggests some steps we can take to manage these things we call requirements.
See Frank Hayes’ “Frankly Speaking” in Computerworld , April 16, 2007, titled “No Fear ”. He describes the love-hate relationship between managers, programmers and tools. He describes the situation nicely, but gets the causes all wrong.
The customer wants measurable business improvements with a fixed budget. However, their Statement of Work limits us to a few technology changes. I want a Bentley to appear in my driveway. I think I’m being more realistic.
I’ve started to identify some other Requests for Faerie Dust™. See Faerie Dust for an early take on this. Here’s another potential symptom.
In reviewing Processing Rows in Batches I realized that the customer wanted a Faerie Dust solution. How do we break the news that we don’t have a supply?
Can end users write use cases? Should end users write use cases?

There seem to be three attractive sinks for time and energy: Stepping in Sequence , Free-Running Imagination , and Follow the Precedent . These distractions dilute the value of the use cases.

We feel that a business analyst should (1) help users identify the indirect or intangible value created by a use case, and (2) challenge every part of a use case that does not contribute to the expressed value.

The use cases, while partially narrative in form, were not interactive and were dominated by processing details, including algorithms, database structures, and processing components. Lacking any defined user interaction, the uses cases presumed that all data was perfect, all processing inevitable.

Since the use cases gave a very specific processing sequence, irrelevant to the actual results desired, it was not possible to make otherwise transparent changes to the processing.

In [link ], I ranted about mutability: defining degrees of mutability from the immutable to the fungible.

Recently, I’ve seen some additional odd uses of numbers that butt up against this spectrum of mutability.

The customer contacted two large software and services companies for proposals to build a complete web-based solution. The initial set of use cases were not narrative in form; they did not contain sequences of interactions between an actor and the system to create business value. Further, the description of the various login scenarios provided by the customer implied some additional use cases not present in the documentation.

The use case issue is that users often cannot focus on the business problem, they will either describe a specific solution or speak hypothetically about potential solutions.

It’s difficult to work around because it comes from a management interrupt, and all my lands are tapped out. And there’s this whole side battle going on that (I hope) will eventually get an old, bad solution card off the table.
Kenny and the Master debate good design.
Part 2 - Denormalization of Hierarchies
Use Cases can become very hard to do when there is a GUI expressed or implied.
A useful description of a problem is often a hard thing to write.
When do you drop C++ for Python? PL/SQL for Java?
Do we have a problem statement? Are we solving it or working around one of the causes?
Three Rules of Deferred Decision-Making are “Focus, Focus, Focus: Solve one problem at a time.”
How predictable is software, really?
When we embed explicit constraint checking into a design, they can occur in any of the available tiers: persistence (database), access, model, control or view. What’s the best choice?
What can change? There are two principal considerations: requirements change (problem-space), and effect of the change on the software (solution-space).
 
 
 
Part 1 - How to spot a multi-dimensional data model. (Revised)
 
 
 
 
 
 
 
 
 
 

The soil is not in the backyard.

How does IT address problems like this one?

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

iBlog

Next topic

The Python “Connection Reset By Peer” Problem

This Page