Interesting Design Sessions

Had two interesting design sessions yesterday, both of which got me thinking / observing …

Push to Prod

A team of techs, working in a Unix / Progress environment (QAD MFG/PRO eB2), reviewing our plans for improving our Dev/Test/Prod cycle for controlling / auditing the movement of source between environments. A little history – we didn’t get off to a good start because of two key mistakes:

• Mistake #1: We started with the concept(s) of Development, Test, and Production environments, but then we named the first three environments DEVL, TEST, and PROD

Our biggest problem: in conversation, it was never clear if folks were talking about a development environment (a concept, an object) or the development environment (an instance of the object). This was exacerbated by our team full of smart, young techs who are eager to demonstrate their ability to solve the problem. Unfortunately, we needed to get agreement and understanding of what the problem was.

<side note> There will always be terrific value placed on folks who can successfully, succinctly, and simply define the problem – heck, most of the battle is over by then. A clear definition of the problem, and consensus among those impacted that this is the problem, makes for less spinning of the wheels / wasted effort.

<tangent> Careful here: classic management exhorts us to not just define a problem; better to define a solution. That’s a tad oversimplified; you certainly don’t want to walk around defining problems and offering no help or ideas to drive to a solution. However, we must fight the classic techie urge to jump to a solution without first having a decent definition of the problem.
</tangent>

</side note>

In fact, the success part of the meeting was helped by the lack of computers – whiteboard only. Also, I got to pull rank – apologizing all the way, of course, but forbidding people to use certain words in sentences. Yes, a critical part of the solution was to identify new words to describe the concepts.

Now, we speak of three types of environments (Wild West, Unit, and Sacred), and then discuss what state a given physical environment is in. And yes, a direct quote from the meeting at about this time was “well, now that you describe the problem like this, I see where you are going …”

Bingo – we’re well on our way to success now …

• Mistake #2: We treated the version control system as the staging area / source for “gold code”

Not sure why we made this leap, but our current process takes “latest and greatest” version out of source control to start the compile / push process. Okay in concept – if you religiously finish all work in process before the big push. Unfortunately, this is (typically) not practical, as many projects are underway at any one time, in different stages of completion. This makes it difficult to automate a deployment.

Not all of our platforms work this way; we have a “staging area” / “gold code” folder for our web development projects, and deploy to that; an automated, audited, multi-generation process synchronizes staging and production during off-peak hours.

Solution is easy, of course – define a place separate from source control where the “gold code” resides.

<side note> Note, fellow techies, that this is Progress/4GL, a development language and database; the “source code” we are “compiling” also involves data base schema; when pushing to production, we have to develop processes that accomodate schema changes as well.

<rant> Sorry, but I am still amazed/dismayed by the tight connection between the source code and the database schema in Progress/4GL. If I change the database, even something as simple as adding a column to a table or hanging an alternate index off an existing table – I have to recompile every program object that uses that table!! Shades of RPG II and I-specs in every source file …
</rant>

</side note>

then I was late for lunch, had to duck out … and back in time for the next design session …

Hyperion Integration

In our Finance group, we are implementing Hyperion Financial Management (upgrading from Hyperion Enterprise, so we’re not 100% green here), and we were struggling with the need for significant / simple integration development using Hyperion Application Link, aka HAL.

<whine> Struggling with the HAL tech’s hourly rate, which is rivaled only by the Nortel phone switch programmer … I gotta read that manual and hang out a shingle …
</whine>

Up to this point, we’d had a number of separate conversations about our difficulties with HAL, and how the HAL development / rework promised to be a budget buster. These discussions were always hand-waving affairs, where broad statements were made about various business units’ resistance to using the tools provided. Did we need to automate all of the questions / problems away, or were there sonme expectations / training areas to address (in order to keep implementation cost down)?

Breakthrough moment came when a key business process owner (KBPO) described a problem instance:

KBPO: When HAL can’t translate an input file, it gives an unacceptably terse error message.

Me: Wait, HAL doesn’t “translate” input files … the Hyperion Translator does that …

KBPO: Oh, when I say HAL, I mean the whole thing …

As above, the success of the meeting revolved around getting a common understanding of the nature of the problem – exactly where the problem was.

<tangent> Is this another manifestation of our sound bite society? Too busy to slow down and think, always looking for the shorthand way of expressing ourselves – without checking our assumptions about understanding abbrev.’s?
</tangent>

Of course, the meeting went swimmingly from that point on, as all in the room were experiencing the same revelations at the same time.

Key Learnings for the day:

• Be very, very specific when defining problems, requirements, specifications, etc.
• Invest the group’s time in open discussion – everyone needs to hear how others are expressing the “same ideas” (which are often not the same)
• Don’t assume your lunch appointment is picking you up …