I came across my copy of the magazine when I was clearing one of my bedrooms out a few days ago (after heavy rain seeped in through the flashing that sits between slab and wall and started the carpet rotting. Sigh.).

The article was entitled “Under the J2EE Umbrella.” No prizes for guessing what the article was about :-)

Neither SEA nor ‘Software’ exist any longer (wound up in 2005, I believe) but sadly, I have no idea of the copyright/ownership of these golden words so I can’t actually publish the article.

Still, this should help me recall doing this, when I am old(er) and (more) forgetful.

I (currently) remember writing other articles for ‘Software’…don’t know if I still have copies of those lying around…

Transentia is Ten years old today.

Transentia is a baby of the dot-com era. We started out wrangling Java and are coming into the second decade having adopted Groovy as a technology platform.

This is a good time to reflect on the origin of the name…

It all started while I was a member of the “Business Development” team at DSTC.

After a session wrestling with a group of research staff (collective noun: a recalcitrant?) a colleague (who shall remain nameless) stormed into my office and yelled “I don’t know what we are doing, but it sure as hell isn’t technology transfer.”

He came up with the phrase “Technology Transferention”, explaining: “It sounds good and can impress people who don’t know any better, but it doesn’t actually mean a darned thing. Exactly right for what we do.” That phrase got a fair bit of mileage :-)

While casting around for a company name I recalled this event.

I decided that “Transferention Technologies” was a bit too much of a mouthful and munged it around a bit; thus the name Transentia was born.

(The alternative was a play on another phrase the team used when confronted with an absurd situation: “the sky is green, the trees are blue.” That got a lot of airplay too, but I couldn’t quite work it into a good company name: “Green Sky Technologies” sounds a bit too vomit-induc{ed/ing}.)

Nowadays, there’s a “Land of Transentia” in some online game, a (Japanese?) musician, and a cybersquatter is sitting on ‘transentia.com’ (and can continue to sit, as far as I am concerned. I deliberately chose an australian .com.au domain…we are a much more exclusive club :-))

Date: Friday 9 October 2009
Presenter: Tim Rubin
Venue: Augustine’s Mansions Private Dining Rooms

First (as always), I’d like to say “Thank You” to Oracle for inviting me along to this event. Even if they actually wanted “Dale Gately”, whoever that is (the email just happened to come to me via my domain’s default drop-box). I guess that I should say “Thank You, Dale” as well! Never look a gift-horse in the mouth :-)

I’m not sure that there was actually any ‘Strategy’, “Best Practices” OR “Lessons Learned” discussed in the presentation.

The guy sitting next to me summarized his response to Tim’s spiel as: “Please don’t buy into what our competitors are telling you…give us time to work something out…” I guess that’s about right.

I loved the opening Larry Ellison quote on Cloud Computing:

The interesting thing about cloud computing is that we’ve redefined
cloud computing to include everything that we already do. I can’t think of anything
that isn’t cloud computing with all of these announcements. The computer industry
is the only industry that is more fashion-driven than women’s fashion. Maybe I’m
an idiot, but I have no idea what anyone is talking about. What is it? It’s complete
gibberish. It’s insane. When is this idiocy going to stop?

We’ll make cloud computing announcements. I’m not going to fight this thing. But I
don’t understand what we would do differently in the light of cloud computing other
than change the wording of some of our ads. That’s my view.

The participants (all CIOs and CTOs…whoever Dale Gately is, he’s clearly more important than I am) were…a confused lot, it seems to me. This is what I picked up on:

• We are going to ‘do’ “Cloud Computing.”
• We don’t really know what it is.
• We don’t really know why we should be doing it.
• We are sceptical that it will buy us anything. At all. In fact, all we can see are a myriad of problems.
• Still, everyone tells us that we should ‘do’ “Cloud Computing”, so we will.

The event’s organiser/host made an interesting comment something along the lines of “In Brisbane, we always meet with a healthy ’show-me-the-money’ attitude. Much more so than in the other states.” Decoded, this means: “Damn! You luddites are giving me a hard time again. I didn’t get this from Sydney or Melbourne.”

One question was repeated a couple of times with various phrasing whch I’ll summarize as: “If we do ‘do’ “Cloud Computing”, will we still have to do all that yukky Systems Integration?” I’d have hoped that a roomful of CTOs and CIOs would have a bit more of a grasp on things than they apparently have, but that’s life. To his credit, the presenter’s answer was quite correct: “Of course! You’ll still need to undertake a good round of Business Process Reengineering to get the benefits of this (or any new) technology.”

A few interesting tidbits/notes:

In a typical data center, the Uptime Institute found that up to 30% of servers are ‘dead’ (ie with <10% utilization).

According to Tim, the major benefit of Cloud Computing is reduced time/cost to provision a system.

According the to Oracle Cloud Computing survey:

• ~24% of respondents saw cloud computing as a way of saving (unspecified) costs
• ~20% saw (unspecified) ‘Architectural’ benefits
• ~18% considered Cloud Computing to be strategic, in some unspecified way
• ~15% considered that Cloud Computing offered a revenue-raising opportunity

Tim gently made fun of these statistics by pointing out how they seem to show a herd mentality following a fad (my interpretation of his comments).

Tim pointed out that Cloud Computing may actually cost more than self-hosting if you provision it properly and account for it fully (without all the funny intra-organizational ‘tweaks’ that are often so beloved).

The fact that Cloud Computing introduces a whole new swag of failure modes, critical infrastructure points and training issues was pretty well glossed over (and would probably have taken all the allotted time anyway!).

SLAs and legal issues were almost completely ignored.

IMHO the SLA is probably the most critical aspect of Cloud Computing adoption, and here’s why:

Let’s say I buy into a cloud on the basis that my cloud will be provisioned for a ‘normal’ load, but can be scaled on-demand to enable me to handle the bursts that come along every now and then. Everyone in an organization does their timesheet on a Friday morning, so that’s a good illustration. The timesheet system probably runs at 0.01% of maximum load during the rest of the week and so constitutes ‘waste’, according to the Cloud Computing credo. Consider that the cloud vendor is only going to make money by ensuring that his infrastructure is as maximally profitable as possible and so wants to handle the load with as little equipment/effort (= as highly shared between customers) as possible. How do you write an SLA that says: “I need my peak load traffic to be successfully dealt with, REGARDLESS of the traffic being offered at the same time by any of your other customers.” All the other customers have their timesheets to fill in, remember; their peak is Friday morning as well. The only way a cloud vendor could make an appropriate guarantee would be to provision a data center in exactly the same way as we do now: for maximal utilization and accept that the normal usage is going to be very wasteful. This will fly in the face of the vendor’s business case and make their life almost prohibitively expensive.

So: you want to be in the cloud? Expect to achieve worse service (in some unspecified/unspecifiable way). You may not get bitten, but you WILL need to decide how painful a bite you can potentially stand.

Tim makes the very good statement: “Any application that gives you a competitive advantage should NOT be in the cloud.” Good advice.

Overall, I came away feeling ‘unenlightened’ and a little miffed at the shallowness of the coverage.

I didn’t even get a desert at the end of the meal ‘cos the caterers had run out :-(

It has a tag on its ‘behind’ saying “Hi! I’m Tux The Linux Penguin” The badge has the heading “Penguin Power.”

The badge also uses the quaint spelling ‘LinuX’, which proves how old it is: who would spell it that way nowadays!

I was presenting a 2-day tutorial session on Linux (RedHat 5.2). I have mentioned another trophy before.

This T-shirt is a fairly recent acquisition, from the Energex/SPARQ TCE Project that I have written about before:

This one is a lot older:

It was given to me by one of the Enhydra guys in December 1999 at the Linux/Open Source Bazaar, Jacob K. Javits Centre, New York. I was presenting a 2-day tutorial session on Linux (RedHat 5.2).

My “body clock” was exactly 12 hours out of alignment but it was a lot of fun. For example: the organisers arranged for us to have free, unfettered access to the famous FAO Schwartz Toy Store for a night…the perfect entertainment for a bunch of geeks! Another choice moment: watching the audience practically boo Corel CEO Michael Cowpland (I think; might have been RedHat CEO Bob Young….my jet-lagged memory is a little hazy here but it keeps pushing a fedora at me…) offstage for daring to suggest that Linux would eventually have to be commercialised and become a money-making product before it could actually “rule the world.” Richard Stallman and Eric Raymond were practically having fits, as were many of the faithful in the audience. How times have changed…

This was pretty much the first ‘real’ Transentia engagement, so this T-shirt really does bring back a favourite memory.

The task was to produce a suite of applications capable of browsing the fairly substantial amount of live and historical/archived substation data.

Man, I gave myself trouble!

Like a fool, I insisted on the “buy not build” mantra right up to the point when it became clear that–wish as I might–it was really not possible to buy anything that could handle the type and quantity of data involved. To be more precise, the available budget was a few orders of magnitude smaller than the available commercial toolsets but the effect was the same.

So: having expended (wasted is a little too strong a term…there were some learning outcomes, after all) a fair amount of time attempting to bend the likes of Eclipse BIRT, Pentaho and Crystal Reports to my will, I was faced with having to build a large-ish integration framework and associated suite of applications from scratch in a compressed timeframe.

It goes against the grain but OK…time to start building from scratch.

I chose to use a graphing tool called TeeChart. TeeChart was recommended to me by a colleague who had used it before and trusted it. A few bugs aside, it works well and can handle lots of data quite nicely. As for the rest: Spring and Spring modules (Caching, Valang); a four instance JBoss cluster on RHEL4; JRockit as the JVM…

All went well, initially. I hummed along putting together a nice swing-based framework allowing for the integration of disparate datasources and it finally seemed like I was back on track.

Until this point, I had been building with Spring MVC/Webflow but I had wanted to “move on up the food chain” and get the company using JSF. I duly adopted RichFaces and set about building a nice, tabbed interface.

This hummed along for a while until a ‘gotcha’ appeared (you knew one would, didn’t you…).

In my design, each tab in the UI would represent a parameter-entry form, designating the required datasource and associated query parameters. This could be templated out easily enough into small included files, would be quick and easy to understand and so would be correspondingly easy to build.

(You will see the sort of interface I was trying to get build when I get to the Swing app. that was part of the application suite, a bit later in this tale of woe.)

There is a little entry in the facelets FAQ entitled “I’m getting Duplicate ID Errors (and Bindings)“:

This can be caused by a couple things. The first is when you use JSTL or logical predicates in your templates which add or remove components based on some volatile logic in your model. It’s not so much the case that your component tree can’t change between requests, but you do open opportunities for errors to occur. Sometimes explicitly providing id’s to your components corrects this problem such that JSF has no way of accidentally assigning a duplicate.

The second way this can happen is when you using ‘binding’ attributes on your components. If you are binding components to anything other than request-scope, you can run into problems where components, and their assigned identifiers, get injected into another page, conflicting with their identifiers. Again, you can attempt to provide explicit id’s to your components to avoid conflict and guarantee uniqueness, but it doesn’t fix the greater issue with application/session scoped bindings:

1) UIComponents are not Serializable– and therefore cannot be clustered

2) UIComponents are not thread safe can cannot be used by multiple requests at once

Binding UIComponents to backing beans is actually something worth doing to ease particular use cases. Instead of using a session/application scoped bean, use a request-scoped composite mediator that receives your session beans and the UIComponent instance to coordinate behavior. The injection of your session-scoped beans can be managed with the faces-config managed-property or with any of the 3rd party extensions such as Spring 2.0 or Seam.

Those key-words that I have highlighted shot the whole UI down in flames. I was 80% of the way through and could not continue to use JSF. To this day, I have no solution, and I note that the FAQ entry remains.

I had to restart the UI using basic Spring MVC and foregoing all the AJAX-y goodness that Richfaces would have given me (yes, I could have picked another AJAX framework, but at this point I was well and truly shell-shocked and only wanted to hide under my desk. I definitely didn’t want yet another setback).

I have to give it to my manager: he coped with all these setbacks admirably. Thank you, Gary!

Thus the application suite as shown above was developed.

And shown to the ‘users.’ They hated it!

There had been a long discussion over web-app vs. desktop app that had finally come down on the web-app side. Oh Well!

I had continually been showing the app to various “interested parties”, tweaking and fiddling based on suggestions/feedback. The time to demo to the “world at large” rolled around. During the demo, one of my main contacts decided to go feral and panned everything about the project: the existing system was perfect; the new features weren’t useful (to him); the colors (chosen to be precisely the same) were bad, etc., etc. In fact, it was all a complete disaster that proved how incompetent I and my colleagues were!

Once the dust had settled on this, two facts became obvious:
1. he was one of the developers of the old system and perhaps felt a little ‘threatened’
2. his problem was not with the suite at all, but turned out to be with the settings established for IE6 by the corporate SOE policy.

In the end, much of the fuss came down to one little checkbox:

Once we had set up his IE6 to create new windows as needed, rather than reuse existing windows (and potentially lose what was happening in that window), all settled down.

One never know, does one!

Still, it was decided to ‘deemphasise’ the web-version (it was pretty much functionally complete, anyway) and start on a pure desktop UI that would talk to the middle tiers of the system but provide an IE6-free ‘experience.’

This piccy shows the Swing-based desktop application:

This app used TeeChart (for its already-mentioned ability to handle large datasets, but also because it handles interactivity quite well) with a few SwingX components thrown in.

It is a shame that time/money eventually caught up with me and I didn’t get to complete it.

On the other hand, I was exhausted and happy to see a halt. The project had been a sequence of disasters, technically and ‘politically.’

I’ll never trust JSF again, that’s for sure.

I’m also more convinced than ever that “thou shalt never contemplate one-person projects.”

I built this while working for the now-disbanded DSTC, alongside my colleage and good friend Dennis Remmer. We both continued our involvement after leaving DSTC (I set up Transentia and Dennis established eTwo; “expertise for an advanced internet”)

CoalCraft is a modern distributed system that brings together providers of information of various resources (such as Coal Producers, Power Stations, Transport Schedulers, etc.) through a “brokering” service, to an arbitrary number of users. Information providers are able to maintain their own repository in its native format and provide a window into it by registering with a provider “map.” Information users are able to access real-time information for analysis without requiring significant local system resources for data storage.

The following should give you an idea regarding how it was constructed and promoted:

CoalCraft has been constructed to be platform independent and is implemented in pure Java:
* CoalCraft’s Object-Oriented construction makes it easily extensible and flexible.
* CoalCraft uses Java’s Remote Method Invocation (RMI) system as the underlying distribution mechanism allowing Object-Oriented communication. This provides ease of development and makes it easy to ‘plug’ Providers into the system.
* The CoalCraft client application is constructed using Java’s second-generation ‘Swing’ Graphical User Interface components and this allows for a sophisticated user interface.
* The CoalCraft client application exports data in XML, the upcoming standard format for data interchange. This keeps the system open and allows further processing of data obtained via the CoalCraft system to be carried out with ease.

Here’s the obligatory piccy:

During the early 2000s, we schlepped the system around to various potential users (assisting the client) and even ran a small ‘live’ trial with some interested parties but in the end it didn’t get anywhere (I think we needed a better spruiker and a bit more $$$ for P.R. than was available).

Still, it was “leading-edge” at the time and the client asked me to assist in preparing a patent application, which was a new thing for me so I guess it deserves a small footnote in history…such as the one just here.

This project started at Manchester University and was taken to The University of Essex by it’s head, Prof. Simon Lavington. It’s aim was to make prolog-database-style knowledge management efficient by building a highly parallel hardware search engine.

The project won a couple of awards…a Silver medal from the BCS (before my time, when the project was still at Manchester Uni.) and a Bronze award from the Alvey Directorate (the people paying the bills).

The kit had a hardware “Lexical Token Converter” (a hashtable for symbols), a main controller CPU and 128 custom designed and built search processors, each with 128Mb of RAM (this was the mid-80’s, remember).

You can see this hardware:

It isn’t me in the picture… Actually, I had more hair in those days.

This picture shows two of the systems: the dev/test rack and a finished half-height cabinet (at the right). This unit was eventually shipped off to the University of Edinburgh’s Artificial Intelligence Applications Institute.

My job involved adapting a bog-standard Sun 3/75 VME-bus based workstation to act as the controller for the specialised hardware. It’s in the picture, on the half-height rack. This work was interesting…we even got the schematics for the box from Sun (under an NDA) and eventually found a bug in their hardware. Of course, they found lots of bugs in ours…

I also found myself doing a lot of general Sysadmin-y stuff on a variety of unix-based kit (including SunOS boxes, Microvaxen, High level Haradware ‘Orion’ , GEC-63 stuff). This was also a lot of fun. I cut and sharpened my unix/sysadmin teeth here, and *I* think they remain sharp to this day!

I also played a lot of sport: badminton, squash, tennis. This accounts for the wreckage that is my shoulder these days.

I learned a few useful things on this project:

• All hardware must include 1+ 7-segment LEDs to that you know what the hell is going on.
• It is possible to write one academic paper per decade. All one then needs to do is reshuffle the paragraphs and resubmit…it’ll get published somewhere…
• Any sufficiently advanced technology is indistinguishable from magic (Clarke’s 3rd law); “sufficiently advanced” is not the same as “truly advanced” and is very much according to the eye of the beholder.
• “Thou shalt not work with team ‘mates’ that are continually getting up and coming down.” Nefarious substances can do strange things to people and it is really hard to get a team to ship product when the team doesn’t know what day it is or what state they may have left their wife in as a result of last night’s binge. The threat of physical violence in the workplace is not conducive to one’s best work…
• If a system needs a reboot, people will complain irrespective of how regularly the system is rebooted or how much advance notice was given. Ignore the complainers and remind them that the rest of the world generally wakes somewhat before noon.
• “I just found out…” is not the same as “I just performed world-class research.” Unless you are applying for a research grant, when it is.
• Just because it has always been done “that way” doesn’t mean that it can only be done “that way.”

As an example of the latter bit of wisdom: the Manchester Uni. team had always performed their IPLs (Initial Program Loads) by shipping S-record encoded binaries via a serial port interface on the main board; a slow and error prone process. This is what they had always done. It was what everybody did. Not knowing that, I came along and wrote a 10-line ‘ C’ loader program that ran on a daughter board and simply mapped in the appropriate memory and pushed the requisite bits into the mapped-in segment. Immeasurably faster and easier…

Here’s a little secret: the project was demonstrating to “The Minister” for Science and the hardware just wasn’t working! The software-only simulator was, so we just demoed that, all the while running a diagnostic tool to ensure that the actual hardware’s status lights were flashing happily. The Minister asked a question: “Is it fault-tolerant, as well?” One of my colleagues said “Of Course!” and reached down into the rack and pulled out a known-dud board. The simulator (of course) didn’t miss a beat and the status lights on all the remaining boards kept flashing happily. “Amazing!” said The Minister and walked away, very impressed.

Happy days!

Now an exercise for you, gentle reader: go back and brush up on Clarke’s 3rd law, it you still haven’t understood it…

For all it’s ups and downs, this was a good job. I made friends that I still keep in touch with, I learned a LOT, had a good time and at the end, it was a stepping stone for me to get a lecturer’s post in the University of East Asia, Macau.

One can’t really ask for more from a job, can one!

TCE is a call-centre application that I wrote a few years ago that takes an operator through a scripted interaction with a caller, gathering data as it goes so that an appropriate remedial action can be scheduled before the caller hangs up.

Here’s a couple of piccys:

My CV says:

Development of Energex’s “Trouble Call Entry” call-centre application using the Spring 2.0 Framework with Spring WebFlow. The system is required to support 250 concurrent users and runs using the JRockit Server-side JVM on a load-balanced cluster of JBoss 4.2.0 application servers hosted by Redhat Enterprise Linux 4.2. Performance Testing was undertaken using HP’s LoadRunner tool.

It was a good project and I thank the guys at Energex/SPARQ for getting me in to design and build it.

All the webby technologies that I brought to bear (the Spring Framework proper, Spring WebFlow, Spring Valang, Apache XFire WebServices, Toplink JPA) played very well together.

The host RHEL4 systems also behaved very nicely; I set up a pair of servers in a geographically separate arrangement so that if a rain of dead fish put one site out of commission, at least the other site could continue supporting operations. I had some slight concern about performance but subsequent load testing put my mind to rest on that score.

JBoss (a 4-instance cluster split across the two servers) was simple and reliable, as always.

I learned quite a bit (this is the obligatory opinionated part of the post): about how important it is to fight people’s misconceptions as soon as they arise, about how a good project manager really is worth his/her weight in gold, and about how a bad project manager can be deadly (I am thinking here of one woman who insisted that she would be the sole point of contact between me and the actual product owner and eventual users. “Coders simply can’t understand the business users, so you must always only talk to me.” I stomped on that little impending disaster area pretty quickly!).

I also learned (was reminded again, I should say) that although one can argue a point based on one’s experience, any possible argument will mean nothing if it doesn’t talk to the other person’s experience; the comment “my experience tells me this will end up costing you much more in the long run and will lead to all sorts of trouble” really means nothing if the other person’s experiences don’t cover the same context/domain. “How can you explain colour to a man born blind?” (from the philosopher John Locke?)

Shortly after the application went live, Brisbane played host to one of its regular storms and the application got its “baptism.” After the storm was over, I received an email that said, in part:

Feedback from […manager…] was extremely complementary about not only the performance and effectiveness of TCE but all SPARQ supported systems that support customer response.

[…manager…] passed on his and the thanks of ENERGEX for the great work that has been done on our storm systems. He commented that “Looks like the work on our new systems such as TCE, CVU and others worked really well over the last few days as a trial-by-fire. All feedback I have had is that the systems worked well, are good to use, and are very effective. Great step forward, thanks”! – Now for storm season!”

As far as I know, not one bug report has been filed against the application. That’s something to be proud of, I recon.

So: if you live in Brisbane and phone up to report an emergency Loss Of Supply event, you now know a little bit about the software guiding the Call Centre Operator you are speaking to…

This image shows a schematic of an electricity substation. The main panel shows the current to-the-second state of the substation. The image is actually an SVG document that can be zoomed and panned and certain on-screen elements can be activated to actually control the sub’s activities. A given substation may have many panels like the one shown here.

Here’s how my CV describes the BABI project:

Development of a “world first” tool using C/J2EE and Scaleable Vector Graphics (SVG) to enable monitoring/control/visualisation of individual substations in [client]’s real-time SCADA system.”

It was an interesting project.

It is an open-standards based system using all the technologies that any web-oriented Java-head will have cut his/her teeth on. It offered XML-based configuration (and I built a tool chain to automatically generate about 80% of that from existing configuration files [some of which were PDP-11 binary dump files]), It used AJAX before the term was coined and it interfaced with fairly grungy C code (that, I am told, traces its ancestry back to assembly-language code built for an in-house operating system running on a PDP-7). On top of all that, it was written to live close to the hardware embedded in the bowels of a substation and also to provide a service to the corporate network to provide management with up-to-date oversight into the power network.

I don’t think that there is anywhere else in the world that has tried to do both command and control using these technologies and techniques.

I am proud of it.

While I was hacking it, I received a couple of visits from guys from the Canadian power systems specialists SNC-Lavalin who were blown away by the possibilities the project showed. SNC-Lavalin are trying to migrate away from their home-grown technologies and solutions to more open systems. I hope and believe that this project (in some small way) helped point them along the way…

Sadly, other than my own sense of self-satisfaction, I am not sure what else I can take away from the project: from the start I ran into all sorts of opposition from my colleagues (engineers and inveterate C-heads all): it was too slow, it took too much RAM (it ran under IBM’s J9 J2ME JVM on a Pentium II box with 128M of RAM), it used an externally-sourced framework and so was inherently ‘untrustworthy’, Java could never do anything ‘real’, it wasn’t thread-safe (whoops! a little bug there…in the JNI/C side, ironically [that wasn’t deliberate, honest!]), SVG was untried and doomed, ditto Javascript, ditto XML, one can’t trust a browser to support a ‘real’ application, etc., etc.

I’m pretty sure that [client] will do away with it as soon as they possibly can find the excuse to do so (the grapevine tells me that this is already happening). So much easier retreating into a well-tried and trusted comfort zone than trying to learn and understand what they actually have on their hands (a powerful and adaptable bit of infrastructure, if I do say so myself) and we all know that building a whole system from scratch is so much better and more satisfying than relying on open (source) standards like much of the rest of the world…

Note that this was technically a fairly successful project, was driven by management requirements, was demoed to and received management blessing (thanks, guys!) all through the development process, and so on.

Still, when push comes to shove, none of my colleagues want to maintain it and keep applying it…seems like none of them want to be ‘tainted’ by Java…

I must say that I found/find this visceral, ideologically-driven response vaguely depressing.

[This presentation resonated with me, when I first watched it.]

The aphorism that most readily comes to mind is: “You can take a horse to water, but you cannot make it drink.”

That is actually lesson 1.

There IS one other lesson I can take away:

During development, I would be thinking (as one does…sometimes) “here’s something cool that could be done in a later version” or “I’ll probably have to revisit this in 1.1, but this gets me up and running for now” and so on. I didn’t understand at the time that [client] can only really handle the idea of software as “mysterious black box” that is perfect on day 0 and will never be developed further.

[client] does do bugfixes on their code, and occassionally (rarely) adds a new bit of code, as circumstances demand. However, this does not mean that they manage the lifecycle of their systems: they are reactive, not proactive. Engineers fixing problems, not software people maximising, maintaining and developing their investment.

Embedded systems don’t get maintained; they get replaced.

Appearances (and IMHO needs) notwithstanding, I was building an embedded system…

Still…

If you live in Brisbane, your power is being controlled using this application.

As far as I know, no one has been electrocuted yet, so something must be right about it.