The Clifton Method


Four new articles describing the software architecture I use for client and web development:

Part I: Module Manager – Dynamically Loading Assemblies at Runtime

Part II: Service Manager – Instantiation by Interface Specification

Part III: Bootstrapping with the Module Manager and the Service Manager

Part IV: The Semantic Publisher/Subscriber


QA and You


I posted a new article about high level QA concepts posted on the Code Project here.


Working with QA can often be an adversarial situation, but in reality, it shouldn’t be.  The developer, customer, marketing, CTO, CEO, accounting department, and so forth, are all stake holders in delivering a functional, aesthetic, secure, safe, and easy to use product.  This article can only scrape the surface of what those six terms:

  1. functional
  2. aesthetic
  3. secure
  4. safe
  5. easy to use
  6. accurate

actually mean.  Depending on the product being developed, they will be weighted differently as well.  Security may be paramount in a server handling REST requests, where aesthetics is irrelevant because there’s no customer facing UI.  Safety may be the priority in a piece of medical equipment or an engine cut off switch on an airplane.  Safety may be irrelevant in a mobile game application (unless you want to make sure the person isn’t crossing a street or driving while playing the game.)  So, depending on the application, you may be addressing some or all of the above concerns, and the QA process should provide the right balance of coverage based on how those (and things I’ve omitted) are tested.

Ultimately, the QA process is like a mathematical proof – it consists are formal, repeatable processes that validate and verify the application.

Robert C. Martin’s “The Churn”


I rarely (probably never) just post a link to something else.  But Robert C. Martin’s “The Churn” is an absolute must read for all those newbie wannabee waltzing in hackoders that think they’re hot shit with their latest techie-tech.  And is a must read for all those project managers sucked into the event horizon of the bling-hole.

“We need to choose a language, or two, or three. A small set of simple frameworks. Build up our tools. Solidify our processes. And become a goddam profession.”


Office Politics and Sh*tty Code

office politics.jpg

Kent Sharkey on Code Project recently asked this question:

I’m just curious to know how everyone else here deals with poorly written code in pre-existing projects.

Here’s my answer:

A few of the common questions about the code:

  • Is it bug riddled?
  • Is it hard (or impossible) to add new functionality?
  • Does it run only on/with obsolete or soon to be obsoleted technologies?
  • Does it have performance problems, and are those performance problems intrinsic to the architecture (or lack thereof)?
  • Is there a complete lack of unit and integration testing?  Would the code simply benefit by developing a test suite?
  • Is deployment a PITA?
  • Is the project set up correctly?  Does it have development, test, stage, and production deployment environments?
  • Are the tools being used for development archaic?

Regarding office politics:

  • Is the original coder/team still around?
  • Is there an adversarial situation between the coders and the users?
  • Does management b*tch about the problem but refuse to allocate the funds to fix it?
  • Has management become jaded with in-house development and thinks outsourcing / third party COTS, or bringing in a consulting team (at 10x the cost of in-house development) will fix the problem?
  • Does management think patching the code rather than rewriting it will fix the problem?
  • Does management even trust its developers?
  • Do the developers trust their managers?
  • Do the customers (in house or otherwise) trust the coders?
  • Do the customers trust the company / managers?

So, before even touching sh*tty code in an environment rich in office politics, those questions need to be answered and the issues addressed:

  • Managers, developers and customers need to be brought on board with small wins.  This doesn’t necessarily mean fixes in the code.  It also, and much more importantly, means communication, particularly, feeling heard.  And that means not just listening to the complaints, but coming back with a prioritized plan to address those complaints.
  • Develop trust before developing code. That’s a cute slogan, but think about how you communicate a project plan, even a small one, and how you present measuring success, how you communicate progress and obstacles, so the coders, managers, and customers (in house or otherwise) all, and I mean all, feel confidence moving forward.
  • Everyone needs to see themselves as a stake holder. Particularly, that means management needs to be interested, involved, and engaged in the fixing process. No “disconnected” management, the typical “do this by then or else” style of management.  Customers need to be engaged too with testing fixes and providing feedback.
  • Fix the blame game so that people are oriented toward solutions.
  • Get 100% agreement (even if everyone starts at “this all sucks”) and move rapidly towards 100 % agreement on “this is how we make it great.”
  • Instead of daily stand ups of “what did I do, what am I working on, what are my obstacles”, focus instead on “how’s my enthusiasm level, how well am I working with others, how well are others working with me.”
  • Lastly, be honest, and if you think someone isn’t being honest, call them on it. If trust and honesty doesn’t rapidly become the new culture, then accept it and move on to another job where the climate is healthier.

Those are all things I’ve encountered and is the boilerplate list of questions and “moving forward” approach that I take.

1-Wire DS2482 over I2C reading DS199A ROM codes with a Beaglebone

1-wire i2c.png

If that was Greek, it means (probably more Greek) that I got a 1 Wire Pi Plus board[^] wired up to a BeagleboneBlack[^] and am talking to the DS2482 1-wire master[^] over the I2C bus[^] and reading the ROM code off of a DS1990 iButton[^] using a DS1402D iButton cable[^].

Using bottle, also implemented a lightweight server to get iButton codes back:


Fun stuff!


If Shakespeare Were Alive Today

R not Julia the Ruby of the realm?
Go hither and think not upon Ada,
Whose Basic baseness is not worthy a Boo,
C to it sharply and bring Clojure Forth,
Dart away now to her awaiting arms,
As her love for you awaits in the Eiffel tower of her heart,
Like an Elixir to her suffering,
Be not a Hack, a Python in the weeds, but be instead Groovy,
Woo her with Java,
Be Lithe, speak Lucid and without a Lisp,
Utter not a bovine Moo from thy lips,
Instead may an Opal be upon thy tongue,
Your Prolog Swift,
Your Smalltalk small,
Scheme little, for honesty is the Unicorn
upon which no Rust will form.