House of Eratosthenes

I’ve been thinking about the very first job I ever had as a professional software developer. “Project management” was a distant dream, and it showed; there was a big room, with three desks, two salesmen with me sandwiched in between. That was unwise. But I learned a lot from seeing things from an unusual perspective. I remember one of the sales guys took to putting a sign on his desk that said “Nothing happens until the sale is made!” I’ve often wondered if that was some kind of turf-marking exercise. Certainly it is factual; there’s no arguing with it; on the other hand, could the techie guy not come back with something equally factual, like, “You haven’t got anything to sell until someone builds it”?

Here are the two viewpoints, duking it out quietly, under the surface. You have sales & marketing, which are essentially: Convincing people to do things they otherwise would not do. Yeah there’s a lot of stuff about pitches & relating to people & money changing hands, but that is essentially what it is. The other side of it is coding and engineering, designing tests, scientifically evaluating what the tests do & do not prove, managing the requirements and seeing to it that they are met. Making the miracles. Which all comes down to: Convincing not-people-things to do things they otherwise not do.

The subtle slugfest is nothing more complicated than — when you put it all together, what t’heck are we really doing here? Are we convincing the organics to do things they otherwise would not do, so we can get some funding together and use it to convince the non-organics to do things they otherwise would not do? Or, are we convincing the non-organics to do things, so we can put on what they called a “dog and pony show” and convince the organics to do something?

It is a cyclical mission, so both are valid. Since both are valid, that essentially resolves the conundrum…but not really…for we have to settle the matter of, who is the real catalyst. Which specialty, by its very existence, defines the reason everyone is bothering to show up. And which one is subordinate to the other, merely attending to it, bridging the final circuit so it can all go together and the cycles can continue.

It has been my observation that, since these two sides think in fundamentally different ways, once a practitioner becomes experienced in the one, he does not see himself as ever crossing the divide and making a personal success out of the other. And so, people become invested in the idea that their own domain is primary and the other is secondary. The hard evidence indicates only that both viewpoints are valid. It is quiet on which one emerges truly supreme over the other one.

Another observation I’ve been making: I recall in the early years there was a push on among desktop database developers to make their own scripting languages into dominant “real” computer languages, and “train” the software developers like me to use their tools. Their strategy was to get the market flooded with capable coders who were dedicated to their scripted languages, so that customers would feel a push to invest in such an environment so that it would be easier to hire the custom application developers. This, we were told, was to be to our financial advantage: We should envision ourselves as “The Boss,” and does the boss want to hire more or fewer sales people, does he want to hire more or fewer programmers. Well, obviously, the answer would be more to the first and fewer to the second — and if there’s one thing you want to avoid, you want to avoid being the guy that the boss wants whittled down. There’s a certain logic to it, but I’ve never put too much faith in that, and ultimately things didn’t pan out that way at all.

If there’s one thing you don’t want to be, it’s the guy that someone who is not the boss wants in greater abundance. Because if you can work on it for awhile and develop some real skills at it — you can come out on top, having a job the boss wants thinned down. But you cannot count on bringing such skills to the market if you’re crowded out. If you want to build up the kind of skill level that will net you success only if you’re leveraging it in an occupation that is momentarily exploding, but it would be inadequate to keep the paychecks coming in during the lean times, well, you’re not really bringing the kind of gusto you need to succeed anyhow.

I also remember, from that time, the push was toward libraries of reusable code. Stop paying these software developers to write the same code over and over again. Now, I’m not sure what happened to this. It’s given us a lot of technology that is still in active use, even heavy use, but it doesn’t seem to be leveraged toward that particular goal. I was being told by the database guys, over twenty years ago, that my whole livelihood was going to go away because nobody wanted to pay to have the same things built repeatedly. This has been about as successful a prediction as the paperless office. In fact, I would say even less so, given how tough it can be nowadays to find things like staplers, scotch tape, pens, erasers, et al.

This goal has always struck me as a sensible one, driven by an obvious and demonstrable business case. The engineers are not opposed to it at all, contrary to a belief that seems to have been prevalent on the sales side. Who wants to come up with five tests when you can prove the same thing with one? There’s a lot of human error factor involved in coordinating five tests you know. This is what “unit testing” is all about; and then when you make sure all these tested units fit together right, that leads to things like “system testing” and “integration testing.” This part of the effort has indeed matured and become more sophisticated and capable. But I see it isn’t commonplace for these development houses to do what I was told twenty years “The Boss” was going to do, which is, to look at all the first-time-coding projects necessary to make an entire new system really work, and really cut some huge swaths into it by means of leveraging recyclable code. People say “Is there a library we can get that will do something like that?” and they’re referring to something external. The vision, as I originally understood it, was to make the internals into libraries, to de-couple them from their maiden implementations.

You can do both, you know. You can make an internal module whose purpose in life is, “This is how XYZ company handles files” and another one whose purpose is “This is how XYZ company handles strings”. Then you take all these questions about “Doesn’t Boost do something like that?” and settle them within the internal libraries; use all these good things like DLLs and object-oriented design patterns to build breakwaters. Stop the rippling-through-the-entire-system. The ideal situation is, one design question comes up, by the time it is settled only one module has been changed. I say “ideal” because that’s a pretty tough vision to realize, but at the very least, the architectural effort should be going in that direction.

Just like an organizational chart, you know. Here’s a fuck-up…oh…well, that’s Tom’s territory. So here’s an action item for Tom, and Tom I guess has a headache he has to put right before the meeting next week. This is how software development should work. Someone takes on a bug, in order to resolve it has to change three or four things…same thing with the next bug, and the next bug, and the next, and the last one when it got fixed it broke a bunch of other things — that situation is a red flag that the architecture is not a good one. It isn’t sufficiently modular. Well, this is not exactly a thing of the past is it. Customers can pick up on it; they/we see it pretty much everywhere. We see it in our cable teevee subscriptions and our telephone service, and all kinds of other places. This suggests to me that values have changed. The vision is not being aggressively pursued.

I think the vision was thwarted when someone, somewhere, said something about there being no such thing as a bug-free program. In my estimation, this was not a helpful remark. We have “bug-free” equations, do we not? One and one make two; two and two make four. The bugs become an inevitability when the system achieves a certain level of complexity — and the system has become this complex because some module within, has become complex and therefore unmaintainable. Well, modules don’t have to be complex. Wasn’t Lotus 1-2-3 supposed to have been a bug-free, or nearly bug-free, “killer app”? Well, if it can be done one time it can be done anytime, right?

Here we get to a part that has always frustrated me. Software developers, these leaders of technological innovation, very often are pressured to engage in tribal thinking. No, nobody is going to make a case study out of 1-2-3 for good project management and coding practices; if it is a representative symbol of anything at all, it is of dead computer applications, and a whole bunch of user interface conventions that aren’t done that way anymore. So nobody is asking the question “Do I want my project’s pathway of success to look like where this case study went?” the answer to which would be emphatically yes in the case of the Lotus app. They tend to ask the question, “Do I want my project to end up where this case study is right now?” Which leads to everyone coding essentially the same thing.

That is the exact opposite of technology: Everyone laboring to do things more-or-less the same way that some other guy would do it.

President Obama says we can recapture our country’s technology stature by making sure we have more people graduating from college. In the era of American history over which He presides, we seem to be caught in an endless loop of confusing quantity for quality: Clear skies and fair seas are ahead for you, if you’re doing everything the same way the other guy is already doing it. That seems to be the mindset, and I predict it will fail more often than it succeeds.

President Obama says we can recapture our country’s technology stature by making sure we have more people graduating from college.

Heh. Problem is, the types of folks who a) graduate from college, and b) end up being Democratic party stalwarts (which are c, the only people Pharaoh Threeputthotep really cares about), aren’t majoring in STEM. They’re majoring in Protest Studies. Which, I’m here to tell you — and I have near and dear ones in the biz — is the most epic waste of time this side of Farmville. A degree in anything but STEM is five years’ marination in lukewarm leftist cant, periodically interrupted by keggers and football games.

This is because the non-STEM people who end up doing college for a living are, at heart, those salesmen you describe. They’ve turned a junior-high insight about the nature of human interaction into a career — yes, it’s true, pretty much everything social is arbitrary when you come right down to it, and life’s winners win by manipulating those arbitrary conventions to their advantage. All your Art History or Wymyn’s Studies degree teaches you to do is win arguments by calling your opponents racists.

STEM people, on the other hand, have to actually build shit that actually works. Two H’s and an O will make water, no matter how excluded the oxygen feels from its minority status in the stoichiometry and despite the counterhegemonic postcolonial perspective of the hydrogen.

If we graduate more of those people, then yeah, the economy might improve. The horse sense of the average voter certainly will. And the Democratic party would cease to exist.
- Severian | 06/19/2012 @ 08:34
The tech world is full of excellent software that failed because of poor marketing departments (Novell comes to mind). It’s a shame in a way, because there’s so much software that is either difficult to use or unreliable (like the password issue in Outlook/Outlook Express caused by corrupt profiles or the many versions of Mac Mail/Windows Live Mail). But then, I really like software. I like new operating systems and I love abandonware. Most folks just want something that works.
- teripittman | 06/19/2012 @ 12:12
Morgan, you’ve got to give a BSIROHL to Severian…

Two H’s and an O will make water, no matter how excluded the oxygen feels from its minority status in the stoichiometry and despite the counterhegemonic postcolonial perspective of the hydrogen.

Brilliant!

To address the actual post – the way I was taught resuse was more of a DoD-wide thing; they had a software library repository of robust Ada modules that we could use in our programs. Awesome! Didn’t do me much good in my first COBOL assignment, or my second Java one… Apache Commons is what they were trying to do. 🙂

The poorest code in our codebase, in both environments, was that where testing was sacrificed to meet a schedule. Thankfully, we finally got management buy-in for TDD at my current assignment, so we can take a little longer and they know that, even if they don’t like it, when we’re done it will be solid.

Do schedules fall under marketing or development? It could be both. For the developers, it is a goal against which progress can be measured, where previously-unknown issues can result in adjustments and/or redesign. If the marketer presents the schedule as a contract with the user, it becomes a feature. “It does all this BY June 21st!” Then, the schedule loses some of its usefulness, as it is no longer part of the elastic tools at the developer’s disposal.

I have yet to see a project other than my own (and that hasn’t been verified by outside sources, so maybe I’m dorking it up too) that uses component design well. Changes ripple, which Architects completely understand, and Medicators are completely frustrated by. “YOU SAID IT WOULD WORK!” Is it the fault of the Architects, for not foreseeing that their architecture would respond poorly to change? Is it the fault of the Medicators who do not realize that the Architects aren’t perfect? Could be a measure of both.

I’m 100% with you that quantity != (or , ne, or !.equals(), depending on your language of choice) quality. I forget where I heard it, but it was something along the lines of a poor programmer generating 2 days’ worth of finding-and-fixing his bugs for every day of code written. If the goal is busywork (i.e., the façade of work), that’ll fix it. Judging by this administration’s fondness for façades, I’d say he probably thinks he’s right.
- Daniel | 06/19/2012 @ 18:27
Daniel,

thanks for the compliment!

I have to agree wholeheartedly with this: If the goal is busywork (i.e., the façade of work), that’ll fix it. Judging by this administration’s fondness for façades, I’d say he probably thinks he’s right.

Come to think of it, the marketing / coding divide in tech is a lot like the politics / economics divide over there on the left side of the aisle. Tech is about the only field in which the molecular-level guys and the marketing guys sit in the same room and are expected to work hand-in-glove. A car salesman isn’t expected to know how to build a car, let alone the chemistry of the internal combustion engine. From what little I know of it, though (and I am definitely one of those non-STEM chumps), lots of tech firms have marketing guys actually trying to dictate innovation to the engineers. “Whaddaya mean that hasn’t been invented yet?! It’s only two months to E3 and I’ve set up sixteen interviews with Nintendo Power magazine!”

Liberals have the same attitude towards the market. The way to solve unemployment is to create jobs, right? “Interstate re-paving guy” is a job, right? So let’s just pay some dudes to lay some new tarmac down on I-95. Problem solved! Or: Healthcare costs are rising, because the cost of medical stuff is going up. Especially prescription drugs. So let’s just pass a law that says a bottle of aspirin shall cost no more than $3, no matter what. Problem solved! It works for Canada, after all!

The people most divorced from the creation of a tangible thing somehow have their greasy, ignorant paws all over the entire creative process, in other words. They might be salesmen or they might be leftists, but either way it’s a dumb idea.
- Severian | 06/20/2012 @ 07:11

Leave a Reply

You must be logged in to post a comment.

Recent

Items of Interest

Monthly Archives

What They Say

Links

Memo For File CLXTuesday, June 19th, 2012

Memo For File CLX
Tuesday, June 19th, 2012