clarity of purpose

Paul makes a nice comment here regarding whether the “build vs. buy” simple example scales. His example revolves around less clear requirements for the “widget.”

“We still don’t know what we want, but now we don’t know how to get this package to do it for us either.”

Of course, one of the problems in this example is not knowing what is needed. My example of the millisecond resolution timer software package was based around very clear requirements and a very clear “domain of requirements” (I just made that up, but it sounds good). That is, not only did the commercial off-the-shelf (COTS) package meet my precise needs, it also supplied other features useful to me. Features like self-calibration for improving accuracy.

When the purpose isn’t clear, it can be difficult to find a package that meets your needs (or find too many). In addition, it can also be a case where you end up looking for a way to employ whiz-bang features just because they came in your COTS package.

build or buy?

I was IMing with a friend in the Dominican Republic tonight. He mentioned how great it is with the open source community to be able to get various products to solve problems.

“In the good ol’ days,” I jokingly opined, “you had to buy everything.”

“Or write it yourself,” he added.

“Key is to know what to spend time and resources on for a given project,” I noted.

Which brings me to a story. Years back, maybe late 80s, early 90s, I did a lot of real-time work on PC programs (in addition to real-time apps on supercomputers). The client I was moonlighting for needed a millisecond resolution timer to record time between image display and test subject making a keystroke. All to support Dr. John D’s research into human responses to visual stimuli.

So, I found some great assembly code that I could write to diddle with the 8250 Timer Chip (if my memory serves me correctly — and if it does, that is scary). Got everything working perfectly, shipped the application, grad students ran all sorts of tests using the software. Perfect.

About two weeks after releasing my application, I spotted a commercially available millisecond resolution timer package from Ryle Design (again, IIRC). Something like $49. I bought it immediately.

I couldn’t rip out my custom code fast enough and put in this new package. After all, unlike my timer code, this package:

  • Was supported
  • Had documentation
  • Had more features (useful ones too)
  • Would get the benefit if many users forcing improvements, bug fixes
  • Would have future enhancements
  • Was code I didn’t have to maintain!

Think about this the next time you choose to build versus buy — or in today’s modern computing landscape — use open source…

“test first” the data too!

no, this isn’t rocket science… just a gentle reminder about why some practices are valuable.

now i am reminded why i had been pushing a team to get the “golden data” identified for a project 6 months ago. By “Golden Data” I mean that data which has been carefully selected — or hand crafted — to reveal elements of the application’s functionality. Though the novel technology for this project is a challenge and is by no means trivial, the data itself has been a big struggle as well, mostly due to inherent complexities in gnarly (a technical term ) health care systems’ actual databases.

you see, the application involves grabbing data from n-many sources, some of which may hold duplicates of other sources. in addition, there are certain key values that are deemed “sensitive” and must be handled properly so that only authorized folks can see the sensitive information.

so, there is a combination of code and rules and presentation magic, etc, that all have to jive. however, there also must be the proper data with which to reveal the intended logic. the code could be right, the rules could be right, but if the data is not right, nothing shows up. then starts the wild goose chase… is it the code? is it the rules? is it the presentation logic? or is it the data? or all of the above?

next time, i’ll be sure to emphasize that we have the precise knowledge of the data side of the equation to prove the existence — or not — of a feature.

Note to Self: write the test from the data side — not just code!

Rest In Peace, Rye

this evening, rye — one of two guinea pigs — seemed to be lethargic. we braced the girls for the ultimate likelihood… after all, gp’s don’t live too long.

i checked on rye earlier tonight. he was no better. i picked him up and cradled him in my arms. i used a dropper and gave him some water since they always drink us out of house and home. i stroked his fur, i looked in his eyes. he was shivering and i figured he wasn’t long for this world. i carefully returned him to a nice spot in his cage with some fresh pine shavings. i laid him down and made him comfortable, with his back against a wooden thing we have in the cage. his piggy brother, Poppy, seemed mildly aware of the distress.

just about an hour ago, i checked again. he had passed on to the other side. he is now where the grass is always green, carrots are forever showing up on the carpet of green grass, and a babbling brook brings fresh water by for all time. (well, actually, he is now in an amazon box, wrapped in a little towel, as i figure the girls will want to say goodbye.)

rye, we will miss your little piggy legs elevating your hot dog physique across our kitchen floor. we will miss your incessant audible reminders that your water bottle is empty. and we will miss your squeaks when we peel carrots or chop vegetables.

rest in peace, rye

pre demo day

today it turned out that we were able to get a demo ready for a preview by the business folks. a lot of visual tweaks, but some functionality as well.

the team is

  • spread across continents — which is challenging at times for sure,
  • involves 6 contractors, and
  • includes 2 developers from client

today things clicked when needed. our tools:

  • IRC chat channel – for coordinating and discussion
  • IM

acceptance tests

Acceptance tests are a way to ensure the user functionality exists in the product. Enough test cases are put in to not only prove the feature is there, but that the feature is correct and robust.

I first ran across the term “Acceptance Test” as it had to do with testing cruise missile jet engines. If the engines passed the Acceptance Test, then they were literally gaining a stamp of approval. The tests ensured, primarily, that the core “feature” of thrust and specific fuel consumption were met.

These were two “end user” features critical to the success of the mission — being able to fly far enough and to have enough power to maneuver.

Unit tests, by contrast are more about the sub-components meeting spec. The fuel control needed various temperature and pressure input signals, +/- 5 volts. However, the end user could care less about these low-level details.

So be sure to think about writing those acceptance tests from the end user perspective!

Another benefit is the ability to have automatic traceability between the feature and the code it touches based on the acceptance tests.

knowing when a feature is clear

Here is the way I like to think about a feature:

Small, client-valued bit of functionality. For example, “Hide data from non-admin user view if the data represents a ‘sensitive value.'”

If the paragraph of text describing the feature is clear enough:

  • the developer can estimate the time required to implement the feature.
  • the tester can write an acceptance test to prove the feature exists and is working properly.

If the estimate or the test can’t be made due to lack of detail, then ask for more explanation about the feature.

Complexity

The urge to fight complexity is strong in me… though on my way to a simple solution i often wade through quite a bit of self-created muck.

however, for a long-term solution — be it an application you are building, or a process you are trying to implement — you should take the time necessary to seek the simpler solution.

remember, (almost) anyone can build a complex solution and over think the problem. it is far more valuable to provide the more cost-effective solution up front that seeks to simplify and provide a high return on investment.

the need for slack

unless you are pulling something heavy, slack is a good thing.

why?

because to try and do something new in your development team will require that you have the freedom and slack time to explore, to learn, to practice.

whether this is for a new process, a new tool, or a new technology… without slack, you are more likely to fail.