Monday, November 30, 2009

Problem with Bug Trackers

I once worked on all manner of quality record systems. Anything from enterprise level ISO9000 incident management systems to team-level bug tracking tools.

The apps were often built under the premise that they "own" the data, so requirements were architected to make them one-size-fits-all solutions with little (or no) attempt to redress the scopes of the complex organizational hierarchy. Concerns of individuals, teams, business groups (or other relatively stable organizational divisions) conflict, and couldn't be addressed effectively by the rigid models. For instance, a hardware engineer could not track a design issue with the formal ISO9000 tool, because reporting the issue to the latter automatically escalated it from a design-phase to-do item to a legally visible "incident" (and notified all managers too).

We knew that teams needed to coordinate amongst themselves and track bugs within their own cycle, but management wouldn't acknowledge distinctions for those areas of application. So most of the needs were addressed through skunk-works tools.

Many of today's to-do list Web sites have the flavor of those skunks-works tools. In particular, the sites tend to see the world as if it were a single flat list of categories, items, or names, rather than as deeply interconnected semantic models. Mostly that's because building semantic models is something few people are prepared to do, and fewer still can justify the cost.

Saturday, November 28, 2009

Surrounded by bugs

I had an interesting dream, motivated no doubt by events this past summer in my yard. In the dream, I was walking down a sidewalk in Raleigh, body-pillow in hand, and passed a 2-person crew of city employed exterminators. They were polite, greeting me, and going about their business. Except that they didn't warn me that I was walking into an area they just treated. Looking to my left and right, front and back, I found myself on a sidewalk, surrounded on all sides by what was only now apparent as fire-ant ground.

To the rear near the street, what had appeared to be a baseball-pitching mound sized gradation was actually a fire-ant nest. The exterminators had disturbed it to pump in poison. But elsewhere, around the walk, were ground level spots where they had also disturbed. Fire-ants were just no pouring out in all directions. It was one huge nest. Oh, and I was in sandals.

I had been subject to a "drive-by" by the two workers! It didn't help that they had just poisoned the ants -- it wouldn't kick in for several minutes at least. Now it was no longer a question of whether I'd be bitten, but how to find a way to navigate the path and minimize the number of bites.

Awakening, it occurred to me that this dream was perfectly metaphorical in describing modern Web-based applications work. You're surrounded all around by an infrastructure infested with some really ferocious bugs, any one of which is tiny but the cumulative effect of which can be deadly. And navigating them is a real drain on productivity. Who were the city workers? One represents the well-intentioned standards working group people; the other the technology vendors. (It can be hard to tell them apart sometimes.)

Friday, November 20, 2009

Web developers getting in over their heads

Quoting from a recent posting on a local "Web CMS" group:
"I had a [php webcms] based website, crashed it, and now have a really lame [web host brand] site. I started into setting up a new site but can't seem to stay focused and lack the know how to set something up."

Well, this seemed like such an elegant question, a real teachable moment. The original poster's system imploded under the pressure of an increasing learning curve. My point is that every choice to deploy technology comes with consequences, particularly on-going requirements to maintain the infrastructure.

Open source or not, you need to understand your own needs and constraints first. Never mind that the architectures of Web publishing frameworks are fragile enough that ordinary users can irreparably crash them (an obscure weakness of the O.P.'s particular webcms' architecture).

I won't mention the name (COUGH/DRUPAL/COUGH) , but all the PHP based make-believe CMS's suffer from major architectural flaws and a generally poor fit to efficient work flows.

Thursday, November 12, 2009

The Java Trashbag

Summarized from http://armelnene.blogspot.com/2009/11/10-things-all-java-developers-should.html, this is a list of the things a bona-fide Java developer is supposed to grok.

I summarized this because I'm interested in development. On the other hand, it makes me realize just how much crap people will put up with in order to circle their professional wagons around themselves, and fence everyone else out. It begins to appear very religulous.

Now, I'm not against Java. I like the idea, and I've done some programming in it. But the landscape is looking pretty convoluted. Is it that a lot of former C++/Corba-ORB enterprise developers never learned the lesson of simplicity? The reality is that there are multiple perspectives reflected here, and they don't really come together rationally. (I've commented on that lack of rationality before.) It is likely the case that developers who can check all of these items know little more than surface exposure and cookie-cutter reuse of sample code.

I note too, that the writer omitted any mention of layered or tiered architectures and client-server or peer-to-peer organization. He also compared SOAP to REST, a classical categorical error which is ingrained among many in the Java community. REST is a design philosphy; SOAP is a message packaging protocol. The two are not mutually exclusive. REST practitioners often utilize privately formulated well-formed XML as both the package and payload. Along with URL addressing conventions selected to facilitate caching, this "raw XML" most visibly represents the REST philosophy reduced to practice, and thus surface details are mistaken for the thing itself. REST means that you use the exchange of representations of objects between otherwise stateless servers to accomplish the goals and behaviors of the system. REST is akin to using bakers carts on a factory floor to exchange parts from station to station, instead of keeping everything inside a single complex closed machine. SOAP can be used in a RESTful manner, just as raw XML and URLs are often mangled to implement interfaces to stateful systems.

The list

Java, OOP, and the the core library idioms
ex: What's the diff between using String, StringBuffer, StringBuilder?
Why implement interfaces instead of subclassing abstract classes?

Character of The Platform
Subsets of the Java2 platform: ME vs EE vs SE
Deployment choices: Applets, Servlets, EJBs
JVM Hosted Syntaxes: JavaFX, Groovy, Jython, JRuby, Clojure, Rhino (Javascript), Scala...
JVM configuration and JRE, SDK differences

Enterprise Development Frameworks: Spring, EJB, JPA/Hibernate

Some Scripting Skills: Python, Perl, XSLT, Ruby, command shells...

Basic web service development:
Servlet containers, Tomcat, GAE
ReST and WSDL, SOAP, XML and JSON payload formats

Multithreading: spawning threads, thread intercommunication, thread monitoring

Database Access: SQL, JDBC, JPA/JDO

Web Client Scripting: AJAX, Client-side Libraries (JQuery, YUI, Prototype, Mootools...), GWT

Chose an IDE and learn under it: Eclipse, JDeveloper, IntelliJ...

Build management tools: ANT, Maven, CruiseControl, Hudson...

Accessibiliy? Usability? How about Practicality?

Talking to Saroj led to other thoughts about accessibility in practice as well. She showed a slide set at the Web Design Meetup with the humorous pie chart. Note the yellow and magenta areas in particular.

The shifting sands of Web browsers and server technologies upon which people build their house-of-cards Web sites and pretend-Web-CMS's have limited the potential for truly accessible sites by consuming excessive developer cycles (as suggested by the chart). An even worse roadblock is that the subsurface, founded as it is upon HTML recommendations, is a growing swamp filled with plenty of rotten ideas, many of which were chosen to limit the usefulness and accessibility of content.

Take the DIV and SPAN tags for instance: designers still use them as layout primitives, rather than as purely semantic concepts of "group" and "fragment". I assert that this is still table-based design, just with different labels. People make pure-CSS designs this way, but it is still bad practice. The issue is beyond the idea that one or another screen reader can ignore the markup and more-or-less give something like what a non-vision impaired person might see. The problem is, the underlying HTML formatting architecture is biased toward this kind of practice, so in order to get sites that provide the visual appearance designers are still intermingling markup-just-for-the-purposes-of-layout with semantically meaningful content. Thus we're really not separating "style from content", just CSS style attributes. Much of the layout code is still embedded in the content.

Similarly for guidelines like using an H2 tag before an UL LI
used for menus, from an architectural perspective it is a hack: a menu is not a heading, nor a heading a menu, although both may be considered navigational primitives. Thus we are introducing rigid structures which don't mean what they say, and at that just for the sake of a limited set of reading devices. Which is to say, we are making guidelines to mangle non-semantic HTML to work with a specific vendor's browser because of what it can do today.

I certainly understand the rationale: it is pragmatic. A real tool can read that code, and a person gets fairer access to public sites because of it. That's a good thing. The bad thing is the twisted architecture which then telescopes and reinforces itself by twisting working practices. Like a tree growing around an obstruction like a rock: once grown, the tree remains deformed even if you remove the rock. The BEST practice would be to grow the tree in the open, clear of obstructions. That's what generic markup is about. (And if you want to extend the metaphor, DITA is like training the tree to an arbor. Maybe that's what it takes for farming levels of productivity in generic markup. )

I'm hoping to see more in the ARIA recommendations about this, but given the Web vendors' penchant for throwing obstructions into the language machinery, I'm no longer as optimistic as I once was.

Considering Accessibilty Again

Several months ago, I was considering a technology position at NC State. The position since closed up, but I was fence-sitting anyway. At the time I had the sense that it might be more enforcement or governance than I desired, but after speaking with others I believe I was wrong on that. But I felt that they deserved more than someone who was reticent about the position.

Anyway, the position was for someone who could act as an accessibility guru and technology liaison. This person would help raise awareness of facilitative tools and techniques for making technology services more accessible and usable. Speaking with Saroj Primlani, who had served as NC State's accessibility coordinator for many years prior, prompted me to rethink my rationale.

Not that the position is open any more... it isn't. But I'm not convinced it is as much about enforcement and governance as it is about awareness and efficiency. And that I can buy in to.

Saturday, November 7, 2009

Linking Bipolar Disorder to Societal Change

In my job search, as I peruse the many and varied job listings, I am struck by the cacophonous diversity of voices represented. What used to be called a "programmer" no longer exists in the minds of the people who put together the job listings. Even the era of the hyper-specialist -- "user interface designer" or "back office engineer" -- has been superseded. We've gone beyond, into an area of super-beings: people who can specialize in many areas with several years of experience in the latest technologies. It all made me wonder what effects such expectations have upon the brain structures of people trying to conform?

My first thought is that increasingly complex, dynamic, shifting and expanding points of view would lead to a fractured consciousness. Disorders like bipolar, which may have a learned component, should increase dramatically in times of rapid cultural change. A quick Google search suggests that the rates are indeed increasing. An NIH study paints a pretty disturbing picture of a forty-fold increase in bipolar among youth.

While many may jump to the conclusion that the problem must be due to chemical factors, it is not only chemistry which affects brain function but also electromechanical factors. Neurons and their wires in the brain, dendrites and axons, grow and shrink in response to the challenges with which we are faced in life. That's why athletes don't train by baking cookies, tracking stocks, and learning a foreign language. Instead, they focus on a select set of activities centered around their sport.

Biblical admonitions such as being careful of what you allow yourself to watch and avoiding vain discussions may be thought of as mere moralizing, but from a physiological growth perspective they represent rational strategies for performance optimization and good mental health. So when you hear conservatives express concern over societal issues my progressive and libertarian friends would do well not to just dismiss the complaints as repressiveness.

Your politicians have been promoting Change for Change's sake alone: "Change is Good," it the moto. Your social networks promote excessively rapid interactions and dissemination of half-baked and ill-informed ideas. You already had difficulty reading paragraphs longer than three sentences, but now your mobile communication methods discourage breadth and depth. People who use mobile devices excessively seem to be suffering from a disuse atrophy: their ability to process and formulate long, logical thoughts suffers. Our kids are going crazy, literally. Maybe it's time for a little less "change" and a little more focus.