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
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.
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.
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.
unless you are pulling something heavy, slack is a good thing.
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.
so there we were… watching the system running. we were on the phone, both tailing the app server log file (
tail -f ... ) to watch some progress via the age-old, tried and true, logging statements.
the app is doing a lot… running through more than one data source, dynamically generating sql based on meta data and an ontology, dumping it to a triplestore, running rules (invoking some gnarly stuff), culminating in a report.
it was streaming past at a good clip, then you could see it bog down at one point where there was an especially nasty bit of stuff going down for accomplishing a bunch of rule stuff. Then it began moving again at a good clip. There was definitely a visible “rhythm” just watching each part of the system crank through the dozen or so “sections.”
“I’m pretty sure that is where it is doing the ‘saveToStore()’ call.” I thought it was instrumented with some logging… Hmmm. “Wait a minute” my friend said. “Those rule forms… we don’t need to put any of that info into the triplestore since we aren’t displaying any of that info. The triplestore is merely for running SPARQL queries against to get the info out to the browser.”
“Good point!” I said. So he added one line of code to disable calling saveToStore in the case of no SPARQL being specified. That single change resulted in reducing the time by 70%.
Funny what can happen when a couple of people are almost casually talking through and re-thinking the system behavior. thanks lb
sometimes, in challenging development projects, some of the solutions are out there… you can see them through the mist, or the rolling fog. you know intuitively what the solution should look like. but the implementation can be tricky.
it is worth pushing onward, through the fog, trying to burn it off.
why? because in all likelihood, it is the hard bits of an innovative project that really provide the value to the client.
Just listened to a wonderful keynote by Timothy Lister at GLSEC conference.. A man after my own heart with his ability to say the things many people don’t want to hear about software projects.
This was the first quote I jotted down:
Estimate software projects by the season
It came from his mathemetician father who was reviewing some stats that Tim and Tom DeMarco had gathered on initial estimates for software projects and actual results. His father summarized the granularity of estimates could not be any finer than seasonal!
I was doing tech support for a good friend… seems an email message in Outlook Express would cause the app to freeze. Move to it, and BAM. So, deleting it outright was out of the question. Even archiving the email would cause it to freeze. Mind you, other messages from this sender were fine.
So I thought of a clever way. I created a rule for the sender and the subject, and selected the action to delete the message. Told the app to execute the rule. Guess what? Yeah, it froze again. With the blank outline of the rule execution progress dialog up in all its blank-stare glory.
My response as a professional software person? Besides embarrassment for our entire industry, I said “I don’t think I could code this as a feature if I had to.” (Of course, we all know we could do something clever like “If message number 10959 arrives, freeze app’s UI message handler.”
So, could you code this behavior? Have you ever found yourself expressing such wonderment at amazingly bizarre program behavior?
I am enjoying working on my new MacBookPro after nothing but windows machines, a half dozen dell laptops, etc.
What is really cool, besides stuff just working, is the ease with which I can do development work. The Mac OSX makes it seamless to switch back and forth with the linux server. Most useful!
Getting back on the windows laptop is still familiar territory, but I already find my fingers in the wrong places.
Yeah, the Mac’s weirdness surrounding Control, Option, and Command modifier keys, could stand to have someone bonked on the head with a rubber mallet .