Category: Software

Cox Strategy Redux

It has been a few months since I posted my lighthearted Cox Automotive home strategy game.  In that time, four new projects have been announced linking members of the conglomerate.

Cox Game2

I am still watching for some extension of auction functionality into the used-car department, maybe leveraging vAuto.  No word yet on the development of COXML.

Natural Language Protocol Stack

I was in the lobby of F&I Express last week and one of the OGs asked me, “What was that network protocol that the old IBM mainframes used?”  I replied with SDLC, confidently naming the link level protocol.  “No, the other one.”  I moved up a level, to VTAM.

It turns out he was looking for System Network Architecture, which is not a protocol itself but the name of the stack.  This was IBM’s proprietary stack, competing with Open Systems Interconnect.  Where SNA had SDLC and VTAM, the OSI has Ethernet and IP.  It is easy to find a chart of your favorite communication stack … except this one:

Stacks

I learned about SNA on the job while studying linguistics at college, and I could not help noticing that natural language also uses a stack.

At the lowest level is phonetics.  This is the equivalent of the green light on your Ethernet port.  It means that you are successfully hearing the other person, although the grunts and squawks of human speech carry more data than binary bits.

The next level up is phonology, where different sounds (Greek allo-phone) are resolved into units relevant to the given language.  In German, for example, /ch/ is the same in “ich” and “ach,” even though the sounds are completely different.  Closer to home, English /p/ is sometimes aspirated and sometimes not, a distinction audible only to Professor Catford.

The next level up is morphology.  Yes, I might as well do the whole stack, now that I’m at it.  Morphology is the study of word parts that carry grammatical information, like –ing, -ed, and –es in English (and more exciting ones in other languages).

Once we arrive at the level of whole words, we can study them on their own, plus how they have changed in sound and meaning over time.  The fields of comparative, historical, and social linguistics are each fascinating in their own right, but I will stick with the stack concept for now.

Grammar in Western languages is easily understood as “how to put a sentence together,” using the appropriate numbers, genders, cases, modes, and tenses.  Other languages are not so straightforward, though, and the term from my day job, “message syntax” seems more correct.  I have, at the moment, just finished writing a two-thousand line message syntax specification using XML.

Once we have sentences, we can have a dialogue, or “discourse level grammar.”  This is the application level of the stack, and familiar to all software people.  Our trade is filled with terms like dialogue, request, response, and transaction.  My favorite such term, going back to my IBM days, is “pseudo-conversation.”  Yes, that means just what you think it means, whether you’re talking to a bored spouse or a teleprocessor.

Life (Credit Life) without Recursion

I was chatting with Tim Gill the other day about auto finance math, and the topic of recursion came up.   Tim is one of the few vendors in this space with his own “calculations engine.”  Otherwise, there are not many people who will talk to me about esoteric math problems.  That’s why I write a blog.

People commonly describe Credit Life as a recursive calculation or, more properly, an iterative one.  This is because the premium must cover the amount financed, and the premium is itself financed.  So, if we write the premium as CLP, a function of the amount financed, A, then:

Fig1This is generally how people solve it.  They run a few iterations, and CLP converges quickly.  This is a preference, however, not a requirement.  Assuming that the premium calculation is distributive over addition, which it is, we can just as easily set the problem up as:

Fig2… which can be solved analytically.  This approach will work for most of your popular recursive calculations, like GAP insurance.  For an example, let’s take a typical “cost per thousand” insurance calculation, where f works out to ten percent.  You could go the infinite series route, which looks like this:

Fig3

Or, you could simply work the algebra problem:

Fig4Now, I know what you’re thinking.  You’re thinking that credit life calculations are far too complicated for this approach.  You may also be thinking that the premium is based on the monthly payment, M, not A.  In fact, these complaints are related.  The payment is directly related to the amount financed, through the PV annuity factor, which combines the term and the APR into this handy relation:

Fig5

So, when you see a payment formula like this one:

Fig6The insurance carrier is actually helping you, by combining the calculations for premium and monthly payment.  By the way, the last time I checked, C# did not have the payment and related methods from VB and Excel.  You are much better off coding your own PV annuity factor, and using it as described here.

Now, if you are designing a calculations engine, you may still prefer to use iteration, for the same reason that you may not want to algebraically reverse all your tax and fee calculations.  It is better, though, to use your algebra and know your options, than to rely blindly on iteration.

Maturity Model for Software Startups

Software companies begin life at CMM Level One, and some of them die there. You may not be familiar with the Capability Maturity Model, but you will never forget your time at Level One. This is where the developers code all night because you need that next feature, to pay the rent. This is where you release new code and then spend all day patching it, in production.

“How many users do you suppose we’ll drop, if we reboot it right now?”

On the other hand, it is possible to have too much process control. I was at a Level Four company once where we had to three-bid a project to plan and initiate a second project that would develop the software. The chart above, from Ron Patton’s book, shows the levels as stair steps.

The model contemplates an otherwise stable company that has weak processes only for software. In a startup, all processes are weak and resources are limited. To be successful, processes must mature in step with revenue. In this article, I’ll illustrate holistic process maturity with some examples.

At Level One, you have limited HR capability, and therefore no diversity training or compliance. You have no benefits, no vacation policy, no travel policy, and no expense audits. Your exposure to liability is huge, for everything from “constructive termination” to respondeat superior.

“The reason for Brad’s separation from the company is a private matter which I am not at liberty to discuss.” 

I looked into this, and found that there is indeed a maturity model for HR. The first step, in my experience, is to crib an employee manual and make everyone sign that they have read it. At least then you can disclaim any actions that go against the boilerplate in the manual. You might also invest in an employment law poster.

At Level One, you also have no marketing function. The sales people roll their own presentation materials, talk tracks, and brand message. The first step is to hire a dedicated “marketing person,” to do sales support and organize your booth at NADA. Actual marketing comes later.

Entrepreneurs are good at tracking their sales and market share. People I work with look forward to their first thousand dealers, a public dealer group, or a big agency. Celebrate each milestone by notching up your process maturity.

I would say that you should be out of Level One (for software) after eighteen months. If you are already taking distributions, while the business depends on “heroes and luck,” then you are gambling. Raise some capital, hire a good manager, and get it fixed. My earlier article, Sales-Driven Development, describes what I feel is a reasonable level of process maturity for a young software company.

Baby Steps

I will close this post with a few pointers for leaving Level One. Basic stuff. Most readers should be able to skip this list.

  • Create a maintenance window and stick to it. Only move code to production at 6:00 AM on Wednesday. If anything goes wrong, people are in the office. It’s also not Saturday, our peak volume day. If you are constantly having “emergencies” that can’t wait until Wednesday, you need to look at that.
  • Implement a code control system with a rollback capability. If the latest build has a problem, at 6:10 AM on Wednesday, you do not start debugging. You push the rollback button.
  • Set up a reliable QA environment, and sync it with the production database. I don’t know how many times I have heard that the build worked in QA but some new data was encountered in production, and it crashed the site.
  • Create a division of labor, such that the developers stop fussing with the servers. Developers love to fuss with  infrastructure, which is not their skill set.  At all.  Hire a professional, or rent one from your cloud service provider.
  • Implement a work order tracking system. Planning at Level One is a “pushdown stack,” which means that yesterday’s panic is still simmering when it is superseded by today’s panic. Start by writing commitment dates on a bulletin board, so that everyone has visibility into the backlog.

Not Why They Hired a Linguist

il_fullxfull.484268216_q56jWe received a resume this week listing every language from PL/1 to PHP. This fellow has some good experience, and a degree in linguistics. Someone remarked that linguistics is the master skill for programming, and then I told my story about Greg Turner.

Greg was a linguist I worked with years ago in the Wayne County public schools. He had funding to develop speech prostheses for handicapped children. Think Stephen Hawking and his artificial voice.

In the 1970s, personal computers were just coming out. The county could never afford to help these kids, except that Greg was building custom gear from scratch. We would crack open a See ‘n Say, pull out the speech chip, and order the rest from the Motorola parts catalog. That’s how I remember it. I honestly don’t know how the stuff worked.

If you studied a foreign language at university then you probably have, next to your foreign language dictionary, a grammar reference. My French grammar is the Cours Superieur. For Greg, the chip catalog was a grammar reference. It told him which chips he could use with other chips, and in what context.

I was the programmer on this project. The third member of our team was an actual EE. “Unbelievable,” he said, shaking his head. Without any training, Greg would read the specs, order from the catalog, and then build these wonderful contraptions. Salvaged joysticks and homemade head pointers. We all agreed it was unbelievable. The children just said “thank you,” with their tinny, synthetic voices.

Sales-Driven Development

Larman BookI invented agile development. No, that’s not as cocky as it sounds. Every development manager I know has been trying to reduce cycle times, forever. At BMW, we did quarterly releases of call center software, and that was on client-server technology. As a profession, we have always been as agile as possible given the tools of the day.

What we call “agile development” is the ability to release software early and refactor it later. People generally overlook the high cost of refactoring, but I’ll save the critique for a later post. You can read The End of Agile, over at Effective Software Design. What I would like to present here is a practical approach that served us well at MenuVantage, and which is still relevant today.

We were operating in a highly competitive, fast moving market. Our sales people would come in and say they had just lost a sale because Brand X had some feature we didn’t. Better yet, they would have closed the sale on the promise that we would have it in next release. The developers complained about “sales driven development,” which, today, sounds like it could be a book title.

Our cycle ran from development on the local laptops, through automated daily builds, to the hosted production servers – every six weeks. I know that the scrum literature talks about producing “shippable” code every two weeks, but few shops actually move to production that frequently unless they are in a consumer market, running AB tests. I assume that most of my readers are developing business software for dealers and finance sources.

One innovation in our process was a second QA environment, on the company extranet, where product owners could preview the work in progress. Business requirements were thin, as I’ll explain later, and the extra environment gave us some ability to iterate within the six week cycle. I dubbed it “rolling QA,” in the process document.

When we deemed that it had rolled enough, we froze this code and moved it to production.   Meanwhile, “nightly QA” would already be in use for the next release (see diagram). We also maintained a second copy of production, called “post-prod,” that we could use just in case we should ever need to diagnose and fix a critical problem in production.PipelineAs each release went live, the product owners would meet to negotiate the content of the next release. This expression, “product owner,” is another thing that bugs me about scrum. In this case, though, the meeting included the legal owners of the company. We might differ over development priorities, but we had absolutely congruent goals for the company.

In preparation for the meeting, we would have pulled together a short list of the highest priority change requests, and estimated them – in hours. We did not use “complexity points,” because sales and finance people are much happier thinking in hours. For one thing, it facilitates a discussion about how many developers there are and how many hours they work. If you are uncomfortable having this discussion, trust me – using an arcane metric instead of hours will not make it easier.

Within the development team, we did use complexity to derive each estimate, by counting how many modules, pages, queries, etc., had to be changed. Contract developers have bid projects this way forever. I am thinking, in particular, of a spreadsheet used by Ernst & Young’s Advanced Development Center. Over time, the conversion factors are updated, so “institutional learning” about the estimates is captured.

We used conventional bug tracking software to manage the backlog. They get better every year. I will note that the last scrum system I used, JIRA, is a repurposed bug tracker. This is part of the reason why I find agile is better for enhancing an existing product than it is for the initial release – but that’s the other post.

My job was to collect high level requirements, write specs, and groom the backlog. Requirements were at the level of, “we need rollbacks so that we can do Sign & Drive.” This is actually not a bad formulation for a scrum story card. Readers will recognize the complexity concealed within this simple request – the UI changes and the math, lots of math.

The goal of the planning meeting was to distill the “short list” into an even shorter list of requests we could accommodate in the release. Don’t be surprised if your short list becomes a LIFO stack. That’s human nature. If something was hot two cycles ago, and it was never scheduled, then it probably isn’t hot anymore.

Development would start the meeting by presenting the short list and announcing how many hours we had available. Initially, we might have been paring a 3,000 hour short list down to 1,500 for the release. After a few cycles, though, everyone was able to predict what the final slate would be. The meetings became shorter and less contentious.

This is where we really enjoyed the advertised benefit of agile – and what motivates me to endorse this approach. The group learned that if we didn’t get all our requests into this release, we could rely on the next one, and the sales team developed a feel for how much they could promise.

Rich Internet Applications for F&I

One of the fun things about my job is that I get to see the latest developments in F&I software.  Back when I did my first credit system, client-server technology was the state of the art.  This allowed a feature-rich user interface, but we had to build a huge point-to-point network to support it.

Web-based systems have dramatically reduced deployment costs but, until recently, the user experience was pretty ugly.  When I left MenuVantage, we were just starting to experiment with AJAX and Silverlight.  Silverlight has a nice grid control, among other things, and can support a page densely packed with controls.  I am surprised we don’t see more Silverlight in the F&I space.

Vision Menu uses web parts, and a clean white page reminiscent of Google.  Web parts are a handy way to segment your page into reusable parts, and also to support personalization.  I saw another system recently, using Flash to good effect – but Flash is not my favorite.  I still think of Flash as a graphics control, and I run a Flash blocker on my browser.  Steve Jobs doesn’t like Flash, either, and it won’t run on your iPad.

Stone Eagle uses AJAX in the latest version of their service-contract administration system.  AJAX is my favorite, because it seems to fit best in the .NET programming style.  With AJAX, Stone Eagle achieves the same rich experience you would enjoy on a desktop application, without the deployment issues.

Process Agnostic

Here’s a tip for designers of F&I software.  The way to win a feature-function debate is to challenge the other guy’s understanding of the process – “when, exactly, is the dealer going to do that?”  A surprising number of design decisions are made with no attention to process.

Man making a business presentation at the office

Standalone product portals are just one example, where the F&I manager has to break his flow for a one-off activity and some extra keypunching.  By the way, pretty much every downstream system must have a DMS interface.

Among experienced designers, two techniques are successful.  One is to have a thorough understanding of the process.  Does he print the menu first, or the finance contract?  The big DSPs have people who study this all day long, on videotape.

The other technique is to design your software to work with more than one process – nonspecific, or “agnostic” in the vernacular.  This is not an excuse to duck process decisions.  On the contrary, you have to choose specific decisions not to make, and then design for various uses.  For example, MenuVantage can read an existing deal from the DMS, or create a fresh one and insert it.  It takes extra programming to support both processes, but it overcomes a likely objection from the dealer.

BMW Dealer Visit

TruckIn my business, you can never spend too much time in the dealership.  I bought a new car over the weekend, and took the opportunity to study their software (they didn’t believe me, that I had invented the InfoBahn).

“Hey, can I sign this waiver electronically?”  No.

“Does this desking system push to ADP?”  Not exactly.

Aeros is a slick little system, certified by BMW two years ago.  I gather they’re in a couple hundred dealerships.  I liked Aeros a lot, but noticed the F&I Manager rekeying between it and ADP.  Just user error, I hope.

The same goes for the menu presentation.  Scratching out the GAP row with a Sharpie is probably not what Maxim intended.

I enjoyed using Zag.  They have a good, web-friendly process, and it gets you close to invoice before the first phone call.  Of course, this cuts into gross – but hey, I drove past the other BMW dealer.  Like many BMW drivers, I will order a car sight-unseen. This makes BMW a prime brand for online selling, and Zag.

The Sad History of Disambiguation

Ambiguity is a problem often faced by software designers.  If a program requests a single record from the database, and multiple records meet the criteria, then we have an “ambiguous” result.  The designer must anticipate this possibility, and provide measures to resolve the ambiguity.

I winced the first time I heard the verb “disambiguate,” in December 2002.  I was working at Route One, where one of our dealer identifiers was found to match more than one of Ford’s.  The speaker was R.J. Bussone, and for all I know the coinage was original with him.  The term has since entered common usage, at least among software designers.

At MenuVantage, we found that we could not precisely identify the model of a given Ford Truck from its VIN alone.  The error message “ambiguous model” was despised by our customers, not only because it placed a burden on them to resolve the ambiguity – but also because few car dealers seem to recognize the term.  One called our help desk wanting to know if an “ambiguous” vehicle was one that could run in the water.

MenuVantage is based in Fort Lauderdale, and it happens that tour-bus operators here use amphibious vehicles called “ducks”.

“Look,” I said to my lead developer, Jeremy, “there goes one of those ambiguous vehicles.”

“It is ambiguous,” he replied, “I can’t tell if it’s a truck or a boat!”