Wednesday, May 18, 2011

Problems with Pictures

A client recently sent a use-case document as a requirements specification, and after quite a bit of discussion the team decided that, while it might have been good as an exercise for the client, the result was still a bit far off -- and missed the point that what the project needs is more dialog.

Well, there are lots of other issues there, but I went looking for use-case examples. Alistair Cockburn is a prolific writer on the subject, and his stuff makes sense in so far as one is following a use-case driven approach.

I was struck by the disconnect between the pictographic use-case techniques and the use-case narrative templates.  Pictures can say a thousand words, it is true, but strangely enough it can actually be very difficult to vocalize what is presented in use-case pictograms.  It not only requires translation, but you have to be a bit of an archeologist and forensic linguist as well, to come up with wording that accurately maps what is in the pictogram. And even then, you probably missed some obscure but important details.

Pictures are great for conveying emotion, giving a fuzzy sense of the breadth and connectedness of parts of the problem, and the intended strategies of a solution. But if they make the reader do extra work or suggest detail that isn't there, that is a bad thing.

Tuesday, May 17, 2011

Par Fried Programming

This is a kind of code smell, or more precisely a coding smell.

Par frying is a technique used in cooking french fried potatoes, the goals being to increase the fat content and crispyness of the product.  In the context of the fast food industry partial cooking is useful because it reduces the time needed to prepare the product for sale at the retail end-point.

In the context of programming, a par frying is what happens when the coding for a given feature is left with small parts worked on but in an inconsistent and incomplete state, during a given coding session. I find that some technology stacks tend to encourage parcoding more than others.

I would guess that parcoding increases jointly proportional to the dispersion of responsibilities around the stack and the time spent performing tasks not directly implementing the application feature (such as debugging interfaces; working around flaws in the technology stack; testing routine features of the stack; and writing internal documentation).

Parcoding can also increase when you are tired, sick, or otherwise stressed.

Some degree of parcoding is normal... it is the vision we keep in our working memory that allows us to bridge the gap and finish with something that is more than half-baked. But technology stacks and applications are so poorly organized that they tend to overextend the working memory, giving rise to parcoding behavior patterns that will feed back on themselves.

There are greater factors responsible for turning your projects into Yourdon's Death Marches, but leaving things incomplete should only be done if you intend to abandon the code. When you par code, that's basically what you're doing: abandoning a half-baked train of thought.  

Monday, May 16, 2011

Ahhhhhhhhhhh! I just tried to use the VoiceOver accessibility feature of the iPad 2 on an ms word attachment.

Painful at best.

The top and bottom of pages are unreachable.

The Voice is horrid.

And you have to see the words and touch them to get anything read???

A screen reader would be simpler.

Thursday, May 5, 2011

Content Libertarianism

Several months ago, one of my Web sites using Joomla got hacked. It wasn't a particularly important site, and wasn't bringing me in any money or giving me any useful exposure, so the best option was to simply drop the Joomla system and put up a holding page. 

Well, the holding page has been up long enough, and I'm thinking through how to do the next site. The problem with Joomla, like Wordpress, Drupal, or any other software-intensive approach to deploying information, is that they degrade at a far too rapid pace to pay back the initial investment, let alone the hidden on-going maintenance costs. 

There are many reasons for the degradation. All software contains bugs and security holes, some of which are known by original core developers at the time you, the software user, deploy your site, but many of which are not.  Every security flaw discovered in the core software, exposes your deployed site to increased risk of hacking. That discovery process, which happens over time, immediately reduces the value of your site. You have to incur the cost of responding by updating your deployed site with newer software, which contains a whole new set of bugs and security flaws. 

In turn, you potentially incur costs to deal with new bugs. If you had made fixes to bugs in the older software version, you will also incur costs to determine whether those fixes to the old bugs are still applicable... such forks to the core software must be backed out if they are incompatible. 

The situation is considerably muddied by a general lack of comprehensive revision control in databases and file-system based media (giving non-repeatable and non-reversible operations), and complete absence of testing discipline in many (most?) Web software deployment strategies. The state of the machine at a given point in time is simply not knowable, so we cannot properly evaluate the impact or mitigate the consequences of changes without completely revoking them. 

Instead, the profession has attempted to deploy even more software, layering one piece of software over another in order to monitor and control one or another aspect of the deployment. The reality is that it usually falls to individuals to act heroically, if they can, or to pay others to act heroically, which can get exorbitantly expensive. 

When your business is on the line, people will pay such costs, but that doesn't change the fact that basically this cost of owning software is a usury fee... a kind of professional protection money to keep the consequences of software bugs off your business' back. The realization that something isn't intrinsically providing positive value, is what gives rise to many clients of a feeling of being extorted. It is as if you went to a doctor to set a broken bone, only to be told that due to the way the doctor chose to set it, you'd have to return to have it reset -- every month for the next 5 years. 

Other reasons for the degrading include the relative unavailability of developers skilled in an idiomatic technology; the waxing and waning popularity of the supporting technologies in the "stack"; changes to public services that your system is interfaced to; the fading of the memories of the developers and stakeholders involved in making decisions that determine how the system operates and how it is structured. Most of all, the goals of the organization operating the site usually necessitate changes simply for the sake of enacting a process -- a communication cycle, performance monitoring, marketing program staging and execution -- and these all have the requirement that stuff on the site change. 

We call that rather euphemistically "content management", but collectively it is really about changing stuff to do stuff that will accomplish goals. The more stuff we can remove from that universe of discourse, the better off we'll be.  

Wednesday, May 4, 2011

Content Management (sic)

"Beware," my System's Analysis instructor warned, "of labeling anything with the word management." The rationale behind the warning is that management is a euphemism for "I don't really understand this." Like uttering profanity when you're frustrated. Or a euphemism for profanity (but you still know what you meant). Or not, but still wanting to.

Content Management is one of those substitution profanities. Consultants like to throw this term around a lot, especially those whose job is to glue together processes and procedures to perform management of content. Because if you don't manage content, it will keep taking those long smoking breaks and won't be  focused enough to be productive.

Lazy freakin' content. But I digress, and now I'm stooping to using lame profanity substitutions myself. The problem isn't that content lacks self-motivation, nor that it needs to be told what tasks it needs to accomplish for today. We don't even really know what content is, at least, not in any way that distinguishes it from information or data. Or stuff.

Stuff Management is a more honest appellation. Since Management when applied to IT problems is most often a euphemism meaning "stuff," Content Management amounts to Stuff Stuff.

I'm all for creating good abstractions, but Stuff Stuff strikes me as a little bit too abstract for practical purposes, and just a little redundant. Content Management should be jettisoned.