Filling Shoes and Killing Trees

§ January 19, 2009 03:09 by beefarino |


The recession has claimed another job, and it looks like I'll be taking over documentation efforts at the office.  Unfortunately, this takes a huge bite out of my time, as we produce roughly 2000 pages of material per release.  So expect some posts about writing good technical documentation along with my latest spike notes.


Not the job I would choose by any means, but it has to get done.  Of course, it makes me wonder:

...if our last professional technical writer is dispensible, and I'm the one taking over his responsibilities,  where does that put me on the ax-list??


Automation Framework pt 0: Vision

§ January 14, 2009 16:16 by beefarino |

After spending the last month reacting to some remarkable system failures at a very visible client, I've convinced the CTO to give me some elbow room to come up with the strawman of an automation framework for the core components of our system.  I described my initial goal to be able to drive the brains of our product without having to have the entire body attached, so we can start automating load- and performance-testing.  I didn't share my secondary goals - to be able to define automated regression tests and user acceptance scenarios that can be run against the system, which I think will do wonders for our feature planning and entomology.

At the moment, doing any kind of testing is a hassle.  Nothing can be automated to behave deterministically, everything is either manual or random behavior (which can be good for burn-in, but doesn't do much for testing scenarios), and doing things manual is to slow to cover much ground past "yep, it starts, ship it!"

The system has the complexity of an enterprise architecture, along with:

  • no standard messaging, communication layer, or service bus - instead we have raw sockets, Remoting, some of it stateless, some of it stateful, some of it persistent, some of it not;
  • numerous pieces of proprietary hardware that are expensive in both dollars and space;
  • deep assumptions about the physical environment, such as every client having a NIC card, to the point that most components won't work outside of the normal production environment;
  • system configuration that is splattered across devices, files, databases, and AD;
  • a codebase that is closed for extension.

So you see, our ability to mock client behavior and bench-bleed the system is pretty crippled.  I don't have time to address all of these things, but I want to knock as many of them out as I can.

I'll post my napkin design in a bit...

There is No Homunculus in your Software

§ January 12, 2009 06:52 by beefarino |

I want to refactor some code to a strategy pattern to isolate some complex authentication procedures, rather than have hard-coded behavior that prevents unit, load, and performance testing.  I just had a very frustrating discussion about it ...  

Developers talk about their code as if it were people all the time.  I do it, you do too.  Most of the time it's harmless, as in this little quip I said this morning:

"So when the service wants to authenticate the client, it will ask whatever authentication strategy is available."

Everyone in the conversation obviously knows that the application isn't capable of wanting or asking, and that these are metaphors to hand-wave over the technicalities of calling on an object.  No harm done; but consider the reply:

"But how would the service know that the client was really authenticated unless it does the work itself?"

Both examples show a kind of anthropomorphism ( like when your car won't start because it's upset with you for not changing its oil, or that your laptop doesn't like the couch because it won't connect to your wireless network there ).  Wants and asks describes dependencies and actions of the software - in short, the software's behavior.  Know attributes a conscious state to the software - that it somehow can understand the difference between doing some work and calling someone else to do the same work, which is nothing short of a direct demotion of a functional requirement ( the service MUST authenticate all clients ) into a software implementation ( this class MUST contain all authentication code ).

There is no homunculus in the software.  There is no little dude sitting in a virtual Cartesian Theater watching the bits fly by and getting upset when things don't happen the way he thinks they should.

Software doesn't know anything.  Software does whatever it is told to do.  If the service contains the authentication code, or if it delegates to a strategy that performs the same action, the behavior is the same.  Given that, if the former is prohibitive to testing, I say do the latter and test my heart out!!

Accountability and Software Development

§ January 7, 2009 01:26 by beefarino |

Jay Field today posted The Cost of Net Negative Producing Programmers, where he describes his view of how the software development industry fosters NNPPs via overpromotion and a lack of accountability.  A good read, with some good points, especially about the total cost of keeping NNPPs on a software team.  However, I don't agree that developers are never held to the same legal and financial accountability as, say, doctors or lawyers.  Consider industries I've worked in my career....

Education: producing software that exposes certain identity information of a public school student, such as their SSN, is considered a crime in some states.

Gaming: code up software for a slot machine with a hidden a payout indicator (like a pixel that turns red when the machine is ready to pay out) and you win a nickel in the joint.

Medical: a programmer can be held liable in civil court if the software controlling a medical device causes an accidental death.  A friend of mine likes to relay the story of a programmer who skirted civil liability by proving that a third-party software library had mishandled a divide-by-zero error that ended up killing three people with radiation poisoning before the problem was noticed.  

And the coup de grâce: as a U.S. defense contractor, if you produce software that leaks secret information to an enemy of the state, you could be charged with treason.  If the enemy leverages the information in a way that results in the death of an American citizen, you become eligible for the death penalty.

You're probably thinking that my examples are obtuse, rare or from highly-regulated industries.  So the lack of accountability is isolated to business software...  

Think again.  Consider that some states, like Oregon, have inane "anti-hacker" laws that effectively elevate corporate IT policy into state law.  Just ask Randal Schwartz about it (that's his mug along-side this post, BTW).  In these states, someone who writes code that even attempts to access what ACME considers "sensitive data" could go to prison and pay massive fines, even when ACME chooses to place that sensitive data on a public network.  If you've ever had to wade through the corporate IT security policy for a large corporation, you understand why this is so freaking retarted and should scare you out of your khakis.

All that said, I do agree with Jay in that I believe the software industry overall to be a prima donna when it comes to liability and accountability.  In most industries when you produce a product that fails to meet its intended purpose, you can be held accountable.  E.g., when ACME makes a can opener that fails to open cans, they can be held accountable for the cost to the end user.  Software is the only industry I can think of where you can produce a product that is purchased by the end-user to meet a purpose, and then force the end-user to agree to a usage license that alleviates you from having to meet that purpose at all.