Shades of Development

I just recently interviewed with a small company that needs someone to be the person who:

• Maintains programs which patch together the pieces of their enterprise, e.g.; do some processing between the Internet order and the ERP system, write reports which draw on the ERP system, etc...
• Identifies (or refines when others identify) and creates process improvement solutions.
• Helps to create / refine content to the web site.
• Does other sundry bric-a-brac.

Now this seems to be a good opportunity:

• The people seem great.
• The company is small and growing fast.
• I would be able to call the shots.
• I would be getting in at the ground floor.
• Productivity is inversely proportional to team size (with the probable exception that 2 are better than 1).

It does, however, illustrate shades of development. One reason I'm code wannabe is that I often come across examples of the work of people who may be called "computer scientists". Or at least what they're doing is something orders of magnitude more compelling and or useful than what the average business developer does.

This position is not one for the computer scientist; nor should it be. The business has a specific gap that needs filling - they need someone to apply the correct amount of lubrication at all the correct points to keep the enterprise at optimum operational capacity. I frankly think I would be very good at this.

One thing they made clear: things move fast, there would be a great amount of context switching, and they want someone amenable to as many interruptions as the business generates. They don't want someone who is a "head down coder with the office door shut". Once again, this is perfectly reasonable, but it's not without drawbacks from the standpoint of a purist (in this case purist being a favorable term for one of those really smart guy programmers described above):

• "Closed door programming" is to be preferred. But again, this presumes a certain type of programming. I wouldn't be creating the kinds of solutions that require intense, focused concentration (at least I don't think so).
• Context switching is harmful. Steve McConnell's quote also comes to mind, "... programming requires more concentration than other activities. It's the reason programmers get upset about 'quick interruptions' - such interruptions are tantamount to asking a juggler to keep three balls in the air and hold your groceries at the same time." I don't think there's any doubt it is a productivity killer. In this company's environment, however, there's probably a greater benefit that outweighs it's drawbacks.

So this company's developer should be much different than many others. This introduces the range of development:

• Corporate developers working on in house applications at BloatedCorp.
• Rock stars creating startup Internet applications.
• Lone developers working under unique conditions leading to killer solutions.
• ISVs creating (formerly) shrinkwrap or (now usually) Internet apps.
• Upper echelon programmers: those who create software for developers. Folks who work directly on .Net or Java internals or on IDEs.
  
• Luminaries like Richard Stallman, Linus Torvalds, or Edsger Dijkstra.
• Contract or independant developers: there's a whole sub range in here.
• Gaming programmers.
• Embedded systems programmers.
• Academics who may contribute to practical projects.
• Monkeys who act as typists for business analysts adding new widgets to code in a system that should be redesigned to be configured directly by business analysts. (That one is a bit specific because it's what I do now).
  

If I take the job, I will probably be busier than a one legged man (you know the rest), so I'll probably have to forebear studying the more C.S. intensive subjects as I am sometimes wont to do. One thing all good developers must share is the constant acquisition of new knowledge; just some more than others...

What's the single best rule to follow in programming?

Actually, I think there are 2 that are equally important; one that pertains to code construction, the other to design (and so it may be the single most important thing). I've recently seen these both expressed in a new light.

The frst (pertaining more to construction than the other) is brevity or code less. The first link, especially, sheds light on just how important this rule is.

The second, one which I'm going to rate as the best rule simply because it always pertains to architecture and as such should have a greater effect on the system under development, is reduce complexity.

The linked interview with software luminary Roger Sessions is the best I've heard in quite awhile. In the interview, Sessions proposes using "equivalence relations" to determine the best possible partitions in developing enterprise architecture.

You can listen to the interview for a further explanation, but I think his best points were about complexity. He demonstrates (by contrasting the huge reduction in potential states representable by a single program with 12 variables [and 6 states] to 2 programs with 6 variables each) that partitioning a system greatly reduces complexity.

Outwardly partitioned programs may not really be, however. If 2 "separate" programs (like services or whatever) share a database, they're not partitioned.

Sessions proclaims OO as the "worst partitioning technology". Now, I've read a fair amount lately in favor of FP over OO, and the arguments are pretty good. But I don't think they came close to Sessions' position against the traditional OO model - the creation of large hierarchies which merely tie everything together. He's not opposed to OO, mind you, just the typical implementation where reuse is a major goal.

"Reuse at the expense of complexity is unacceptable. Reducing complexity is much more important than reusing code; it is the most important thing."

The interview was so interesting to me that, for a moment, I felt excited about things like architecture. Then I remembered that I'm code wannabe and that I work at BloatedCorp (on the Behemoth project) and I snapped back to reality.