Flutterby™! : JIT Coding 2010-07-19 00:19:50.62125+00

JIT Coding

2010-07-19 00:19:50.62125+00 by meuon 7 comments

Meme Seeding: Just In Time Coding is the IT equiv of Just In Time Inventory and all of those other Just In Time _____ buzzphrases. In todays case it was a set of functions that would be called when a complex set of conditions were met. It was an easy set of functions, but a very specific set of conditions involving many systems. 2 years ago the if statement was made and a comment made.

# someday, all of this will happen and you will need to ___________

It's Sunday. It finally happened, all the pieces and systems came together.

Sure, you could call it "sloppy coding" and "failure to create a unit test" or "poorly defined specifications" and maybe even "lying to a client" that the system did _____. But, I'm trying to start a meme. Let's call it: "Just In Time Coding" aka "JIT Code".

It's Sunday evening, the code was written: XML posts sent to another vendors system that has only been online for a couple of months, raw sockets connected to another vendors system that has had several complete interface changes in the last 6 months. Notice text messages and e-mails were sent.. and it all worked flawlessly (close enough, anyway).

No money was wasted shelling out code to API's that did not exist or were changed since 2 years ago. No unit testing failures were reported, and the client would have never been able to (until today) verify that it worked as promised. Heck, it would have taken me a month to setup a one-shot test in an bogus test environment.

So remember boys and girls, there is a new buzzword: JIT Code. Say it with pride and next thing you know your marketing sales weasel types will be describing things in glossy sales powerpoints as "Powered by JIT" or "Certified JIT 2.0 Compliant".

Go ahead, use it in a sentence today. Replace: "I hacked that together with duct tape and Perl and PHP at the last minute" with "The JIT Code Verifier shows that it worked as specified."

I write a whole lot of "just in time" code but, jokes aside, while I'm really good at such ad-hoc solutions, and they often work very well forever after amen, NEEDING the solutions is not very good for my personal stress level. Sanity-checking possible failure modes is something I've learned to do strictly out of self-defense - "What happens if this server that the code is expecting to always be there suddenly goes away one day without warning? If we die there, we need to at least have a useful failure." (Non-useful failure = blank HTML response page, like the one I'm diagnosing this morning.)

Doesn't have anything to do with the amount of abstraction in the code, to my mind, but with the extent to which the programmer was able to "what if" the disaster scenarios. You'll still probably always miss SOME way it can fail, but there's no reason not to try.

Compare and contrast MacPaint. 5804 lines of pascal source, and a little less 68k assembly source included. It's a thing of beauty.

I've programmed industrial control systems using PLCs for the past 24 years. There was a time when the programming I did rarely, if ever, used functions. Reusable code was just code duplicated for each time it was used with the appropriate addressing just replaced. These programs, written in this manner, were extremely time consuming upfront but they had the advantage of allowing for a window within the process and controls craftsmen could watch these programs run and maybe add some diagnostic code to the program and quickly find exactly what was broken in the system. These days development time has been drastically reduced by using functions and objects and such so that a piece of equipment is defined and then the code is just put together like lego blocks and lines are easily duplicated, often by just increasing the size of an array and the limit on an indexer. But now it is impossible to use the program for a diagnostic tool unless those diagnostics were originally in the functions and objects. This also causes all sorts of problems when the design of the new line isn't exactly the same as the previous lines.

I'm currently struggling through Cocoa, and in the process of dealing with all sorts of unfamiliar indirection and abstraction and ... yeah: there's a whole crapload of needless complexity underlying this. I'm not totally a fan of the way that VisualStudio structures C# apps, and it's got its own set of uglies, but all of this architectural "elegance" is a royal pain in the ass.

Especially when I want to do something you think would be simple, like run an Emacs macro to create and attach dispatch methods for every menu option.

Which also explains, I think, the fact that if I don't see iOS4.1 for my iPhone fairly quickly, and if that doesn't bring the speed of my device back up, I'm going to see how I can regress to 3.2. This whole thing has gotten me to thinking about how much otherwise unused abstracted crap is dragging down my user experience on that device, and on so many other systems.

spc476: I've always hated object oriented programming for this very reason. It's not that abstraction, in itself, is a bad thing. It's that abstraction shouldn't be done by everyone and definitely shouldn't be a core concept in the language.

99% of programming is just stringing bits together to make something work. And just because the code worked for one something doesn't mean it should be rolled into an object hierarchy for everything else. As meuon implies, it's OK to have code that will only execute once - and it's best to write that code 30 minutes before it has to execute. It's also OK if that code is untested if you can rollback the transactions it generates. (I learned that mistake when I accidently moved $375K the wrong direction between two accounts - and no one else saw the humor when the guy who tried to roll it back ended up doing exactly the same thing!).

The one thing I appreciate about Perl is that, as Dan has said, is a "write-only language". If you want to make an abstraction, you write a Perl module. Anything written in Perl is meant to run, more or less, exactly one time and then is best copied to /dev/null.

#Comment Re: made: 2010-07-19 01:10:02.850883+00 by: spc476 [edit history]

The more I program, the less I like abstractions. I think I agree that abstraction doesn't scale as much as we would like, and in my case, I find I have trouble following highly abstracted code. Perhaps it my environment (no IDE, just an editor) where I have to grovel through hundreds of files and thousands of lines of code, trying to find the only location where actual work is done.

I hear programmers talk about MVC patterns for the web and I'm just—what? What are you talking about? Take the data, manipulate it, spit out HTML. What's the need for overblown abstracted frameworks that attempt to hide the fact that all you're doing is spitting out HTML (with some CSS on the side). Some logic, some templates, why do we need 400,000 lines of PHP to run a website?

Then there's the project dealing with SS7 … 120 lines to send a single message (and that's 120 lines to initialize the appropriate structures using a vowel-impaired library … (then again, SS7 has been around for years and the ANSI version is almost, but not quite, compatible with the ITU version and …)