a little bug – part 1

The Bug: Certain questions that were supposed to be included due to server-side logic were not being properly included.

There was an odd chain of events… The deeply embedded process (shown below) did not seem to behave properly. A couple of developers set about to test a bit more thoroughly. They discovered that the order of the choices for the questions that were supposed to be included affected whether they were successfully included or not. Mind you… there are only two choices: INCLUDE and EXCLUDE.

Context: The application is very loosely a Questionnaire app…. just so happens that some of the questions get processed by this third-party black box which determines if some of the questions should be required/included or not. Required in the sever process world means “included” in the UI world.

I’ll start you off with some code to peruse, full comments and all:

for each (var qstnTO : QuestionTO in processedQuestionArray) {

  for each (var qstn : QuestionVO in __localQuestionsToProcess) {

    if (qstn.questionID == qstnTO.questionID) {

        if (qstnTO.required) {

        for each (choice in qstn.choices) {

          choice.selected = (choice.displayText == "INCLUDE") ? true : false;

          changedQuestions.addItem(qstn);

          // ?? Not sure if the following is necessary or not

          choice.enabled  = true;

          choice.visible  = true;

          qstn.section.visible = true;

          qstn.section.enabled = true;

          // ??

          break;

        }

      }

    }

  }

Can you spot anything that might point to why the testers saw different behavior based on the order of choices?

I’ll be back later to elaborate…

in the weeds

so why is it that, despite warning signs going off in my head, little angels on my shoulder screaming, i let myself get into the weeds on a project?

when you are in the weeds:

  • you don’t lead
  • you don’t steer
  • you don’t allow others of the team to step up and pick up that ball
  • you only get a temporary boost
  • you can’t sustain it
  • you don’t blog
  • you don’t hang out on forums

i have bonked myself on the head!

back to sustainable pace!!

The Distributed Demo

A letter to the extended team/business/qa mailing list:

There we were… 20 minutes to a 1pm demo. All was set the night before… some “safe” last-minute changes requested by the business analyst (Marc — in NJ).

scrambling to figure out why we suddenly couldn’t get [insurance thingy] RQAs to open, or to rate when they worked an hour ago. i (in PA) make some DB changes, cross fingers, try to open an RQA to test

[DB and App running on servers in the middle of PA]

12:46 <markhanson> i am about to faint [Mark is in CA]

tick, tick, tick

nothing

crap

12:56 <mmatrix>T-4 [mike is in CA]

(mike is viewing the demo via netmeeting and reporting to us.)

i flip caching back on

hell with the test, trust in the force

12:59 <mmatrix> uhoh; faultString (String): java.lang.StackOverflowError

and much else followed that i can’t print (*I* only said ‘crap’ on IRC!)

13:00 marc and harry start demo presentation in New Jersey…

at 13:03 I realized smth was up with Questionnairre #3’s meta data

i point some of the sql scripts that mark wrote long ago to help ensure qstnrs were properly formed…

bang, an errant condition for one of the rules! darn!

13:11 somehow, the choice that the condition was looking for lost its question!

mark: how did that happen?

jon: [shrugs in PA] probably me

I make a quick change to the DB to fix

13:15 <mmatrix> they are demoing right now 🙁

13:15 <mmatrix> (it’s like watching a train wreck in slow motion.)

jon: editng the RQA… waiting… it worked! Questionnairre is healed.

jon: okay, cache back on. do we need to bounce the server?

mark: no, just re-open RQA two more times and it will be cached

jon: cool, i am editing the RQA a 2nd time now

13:16 <jonkern> i am still waiting for a response [the RQA to return]…

13:16 <jonkern> app is transferring data now

13:17 <mmatrix> waiting for what? Do they [marc & harry] know about the problems?

13:17 <jonkern> got it! [The RQA]

13:17 <mmatrix> He [Marc] just did a create new

13:17 <mmatrix>

mark: hurry jon! hurry before Marc hits CONTINUE button

13:17 <jonkern> trying it [editing RQA] again now for 3rd time

jon: someone slow marc down for a few seconds! (I joke)

13:17 <jonkern> FAST, SWEEET!!

13:17 <markhanson> and marc hasn’t hit continue yet!!!!

13:17 <jonkern> and all without the usual demo rodeo clowns

13:17 <mmatrix> will it be too late?

13:17 <jonkern> nope. it [RQA] comes back fast now (<10 seconds) 13:18 <mmatrix> JK, if this works it will be the closest I have EVER seen a demo be cut

13:18 <mmatrix> he is creating new

13:18 <jonkern> ignore the men (and lady) behind the curtains

13:18 <mmatrix> hasn’t continued yet

13:19 <markhanson> i am lol and pinching myself to not lose consciousness

13:19 <mmatrix> here he goes

13:19 <mmatrix> doing BOP [a type of insurance line of business] it looks like

13:19 <markhanson> he hit continue

13:19 <mmatrix> … looks for a place to hide

13:19 <jonkern> did it come back fast???

13:19 <mmatrix> no

13:20 <mmatrix> still nothing

13:20 <markhanson> came back

13:20 <mmatrix> it is BACK!

13:20 <mmatrix> son of a GUN

Major applause and cheering from us!

And much more merriment was had when marc did rate the sample insurance applications and premiums were returned, and he made changes to the quote and re-rated and got different premiums. Sweet, the core concepts of the application were just proven. Yes, we can put a modern RIA front-end on a Phoenix back-end and get penny-to-penny match on the premiums!

Reflecting back… Mike was giving play by play description in the phone of the demo and what marc was doing. Mark was also talking to me on the speaker phone (and eventually other developers joined in). All the while, it struck me as listening to the Apollo lunar landing as someone was watching it, or being in mission control with different folks checking in, but I myself not being able to see.

What a rush!

Harry’s words sum it up:

  • The company is confident that we can deliver the tool to the agents to deliver small commercial insurance.
  • The company has given us a good report card in terms of what they were looking for.
  • Andy [President] is supporting us to the nth degree

[Team,] on tuesday afternoon you told me we could make thursday COB for friday QA build. We actually hit the goal on Wednesday afternoon (especially once Andrew discovered missing LOBs on TEST), and left Thursday morning for cardio exercises:

  • Ken innocently twiddled the main application file,
  • Jon and Mike added something to the qstnr for Marc only to realize it didn’t work and had to back it out, and
  • Jon missed one choice’s assigned question and broke the qstnr!!

Who needs espresso?

Savor the moment… there will be more, but this was a good one. Be proud! I am — of you.

What is Design?

Some recent discussions revolved going back and forth on DESIGN.

For me… design is a multi-faceted thing… Sometimes it is a very high-level part of the overarching theme of what drives an application’s details. Generally, the design is the means by which superior business advantage is gained by our clients.

  • For an insurance agent portal application (gather data about the insurance requirements and submit…) we are building now, one of the running jokes is “Everything is a Question.” That is because my overarching design of the system is a domain model surrounding the questionnaire aspect of the system. Add to the questions meta data for the rating system (to auto-generate the XML stream for rating). The entire UI is driven dynamically by the questions set up in a questionnaire — the sample questionnaire that demonstrates all API features and rules is a Diner! Need a piece of information sent to the backend rating system? Create a hidden question and some rules to assign the answer. Need a fancier UI for some questions? Add a CUSTOM_UI meta tag and the UI will kick off a different component for that question(s).
  • For a patient clinical summary system we designed, the overarching technical aspect of this design was the “Form” — basically a set of information needed for a patient. Working backward from this request, the proper data was pulled in by autonomous agents, shoved into a “worksheet” for processing. This multi-agent system used descriptive “Semantic Web” technologies such as RDF and OWL for knowledge representation, mapping, and processing.
  • For a fire department web-based preplanning system, i used a very brute force technique to implement 50 domain objects in J2EE. Though the 2-tier menu system is table driven, the bulk of the beans are repetitive. Yes, I thought about MDA. Yes, I thought about building it in a completely meta driven manner. But, this was a homegrown, entrepreneurial project, so we used a proven and simple technique that I could deliver more rapidly.

For the first two cases above, the combination of design ideas, sketches, wiki explanations and code will give you the fastest ticket to joining the team and becoming productive.

For the 3rd example, you could jump in on examining source code for any of the 50 objects and know all there is to know about the design and start coding.

design is in the eye of the beholder also… the facets of the design that you choose to share are generally for a specific reason. Maybe for the stakeholder to understand the business value that an advanced design provides… Or, a combination of showing the application architecture + the domain models + code samples for the entire set of layers for the technical architecture is what is best for developers. To discuss the UI design, that is a whole other ballgame.

Another way I like to think about folks (like Ron Jeffries) considering the “Code IS the design:”

  • code is reality
    • design is intent

Software Engineering

do you see much software engineering in your travels?

in chatting with the Sun guys behind the new UML effort in NetBeans, i thought of the following. i have often wondered what has caused such a dearth of interest in software engineering and using modeling tools:

  • the focus on hurry up, get it done/get started coding?
  • people trained in hammering nails, but who have no clue about true engineering
  • a lack of “connecting the dots” between stakeholders/management and what is truly needed for doing software engineering, hence illusions of progress in app development projects, and the lack of transparency into the true cost of lousy-engineering
  • over hyping of tools like Rational’s — which didn’t really work as well as advertised — causing a backlash due to the disillusionment of management/development teams
  • people getting stuck in over analysis and modeling without a purpose
  • the creation of architect roles by people who could not really understand building the code and therefore were relegated by the team into non-essential folks who sit in the corner
  • tools that did not give good ROI
  • tools that tried to do too much
    • later versions of Together fell victim to this (feature lust) and i couldn’t convince peter coad to not include such features

just some random thoughts…

Heinz Kabutz Interview

You can read a nice interview with my friend Heinz Kabutz.

The bits about doing timing for various code approaches reminded me of my early days in teaching C/C++ and doing various compares.

Though these are “micro” performance numbers, there are a couple of key points to take away:

  • You have to measure that which you wish to improve
  • Don’t lose sight of the big picture — clear code is far superior to overly optimized and obtuse code
  • Big performance gains for a major system typically come from architectural decisions, not micro-code

Thanks Heinz!

Doofus Darts

Ever want to hand out “Doofus Darts” to your team?

Anyone who accumulates more than 5 darts in an iteration gets hit with a rubber mallet and has to buy a round — of whatever.

Up and down the team, from developer all the way down to the execs.

Process Balance

The “Process Folks” need to walk fine lines of balance in the world of software application development, IMHO…

While process is good, it is not an end-all. In factory work, Taylorism-based processes can be very valuable. In knowledge work, they can be very stifling and counter-productive. For so long, folks have tried to break up software development into factory-like chunks of processes. If you have that kind of software work, then automate it with a tool, not a human . Otherwise, much of what we do — be it creative or inventive or engineering — needs a much looser set of processes. The smallest amount to ensure “Done Means Done” — and to the right degree of “-illity”. Which is no small feat to express just how good a design needs to be, just how much flexibility is needed, how much maintainability, just what is quality code, balancing ROI of time spent getting code out and time in the users hands for getting feedback sooner, etc.

Striking the balance is part of the engineering mindset; but this requires good inputs from many sources, including stakeholders, marketing, users, architects, business folks, infrastructure, tech support, QA, etc.

SCRUM Mistress

Okay, so there are lots of complaints about SCRUM MASTER certifications being handed out like expensive candy. But is that really what the complaint is about?

Or, is it something else?

  1. Scrum, being primarily about simple techniques for managing a project, maybe really does only take two days to master? (Which I think is believable.)
  2. Quite possibly, most of the dissent and gnashing of teeth could be around *assuming* mastering scrum means that developing a working software application naturally follows?

#2 does, quite frankly, involve a whole (heck of a) lot more than the world’s best scrum master.

Gardening

Building an application is a lot like gardening, or better, farming.

Are you doing a quick app (maybe a flower pot), or a mission-critical app — where you need sustainable farming techniques?