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 .
A good friend of mine, Chris Lank, from TogetherSoft days, is now the CEO of Ivis, proud creators of xProcess. He’s piqued my interest lately (well, not *that* way)!
This looks very much along the lines of a process/workflow dream/vision i have held for years (and implemented independently from them to a beta stage). Ever since working on developing IBM’s (as of 1995) next-gen Manufacturing Execution System, ideas have swirled around how to break the log-jam of classic project management solutions for processes that don’t lend themselves well to simple Gantt charts.
I’ll have to poke around more on their site and talk to my old TS pals that are there. This tutorial looks like a good start…
The GLSEC is being held in Grand Rapids, MI, on 25 & 26th October.
I am scheduled to deliver a talk on “Pragmatic Agile Model-Driven Architecture.”
Carl Erickson figures it just has to be an oxymoron!