Do the right thing...

-
I recently sat down with a group of technical people and I made a statement that now haunts me. The statement was:

"If a developer doesn't know exactly what they are supposed to do, they should just GUESS what they think should be done and move on. "


Once the words left my lips, a technical team lead at the table paled and began to argue about how that statement was totally incorrect. I was puzzled for a moment, but then realised this person probably thought I was implying that they should not EVER go back and ask what should be done. In addition, I think they heard me imply that developers shouldn't ever ask questions in general.

This was not really what I intended to communicate and in retrospect, my choice of words was unfortunate. To clarify, I obviously think people should ask questions, they should openly challenge requirements that are vague, ambiguous, or contradictory. More importantly, they should be free to use their best judgement in the absence of specific instructions. But if it is going to take 24+ hours for a business client (or the boss) to get around to answering your question, make an educated guess as to what you think they MIGHT say, make a note for future generations, fire of the question asynchronously, and continue to work toward a solution.

I'm not suggesting that this is ideal, but nothing ever really is ideal. As an example, a better situation might be that the business client or representative user is sitting within arms reach of the developer and they can simply answer any question immediately. If this is the situation then of course: ask away, have a rousing discussion, argue about it. My point is more that software development is a partnership and having the development team simply delegating every decision to their business partner (or the boss) is a sure fire recipe for disaster. In addition, it will very likely lead to a buffalo problem

In hindsight and to clarify, I think my statement really should have been:
"In the absence of specific instructions, coworkers (peers, subordinates) are authorised to exercise professional judgement to select the best course of action without fear of reprisal"

Comments

Unknown said…
Interesting, I interpreted your original quote just as you intended it. You're counterpart must have a "jump to conclusion" mat in their office.

I always remind the other blockheads at work that although the systems we support are important, they are not used for curing diseases or saving babies so it's okay to make the "gray area" decisions in the absence of the almighty. Like you said, make the call, keep moving forward and back fill the gaps when you get the info you need.

Keep up the posts, I always enjoy a good read.

matt >.<
March 27, 2009 at 8:32 PM
Post a Comment

Popular posts from this blog

Please use ANSI-92 SQL Join Syntax

-
Image
Way back in 1992, a standard was published for SQL. In it, the syntax for specifying joins in SQL Database was finally standardized. This was a good thing because (for folks who've been doing this a while), trying to decode the vagaries of how various Databases handled outer joins could drive you bonkers yielding different results depending on the parse order of things in the from and where clauses. Unfortunately, some DBMS vendors took a while to adopt this standard (Oracle didn't support it until 2001), but at this point if you're using a major RDBMS and NOT using it, you're probably mired in a tradition or habit that bears changing. As an example of what I'm describing, here are some examples of what I mean. Old School (no standard syntax + implementation and evaluation of predicates varied by vendor [and query]): select * from customer, order where customer.customer = order.customerid ANSI way (agreed to standard, predicate evaluation has some rules ...
Read more

The difference between Scalability, Performance, Efficiency, and Concurrency explained

-
I thought I'd give some explanation of the difference between scalability, performance, Efficiency, and concurrency. To make things more accessible (and because I'm watching a cooking show on TV) I'm going to use a baking metaphor to help explain the differences. In our case, the system in question is baking cookies for consumers. Scalability, is how well something responds to adding more resources. If we can double our capacity by doubling the number of resources, we've got linear scalability. In our baking example, if we add more ingredients, we can scale to a larger number of cookies. To contrast with our other metrics, this doesn't actually increase the performance of creating a single cookie (they still take 10 minutes to bake), and the efficiency is the same (we just have more capacity). We also cannot bake more cookies in a fixed time period, but over a larger time period we can produce more cookies. Performance is how fast something can get done, u...
Read more

the myth of asynchronous JDBC

-
Image
I keep seeing people (especially in the scala/typesafe world) posting about async jdbc libraries. STOP IT! Under the current APIs, async JDBC belongs in a realm with Unicorns, Tiger Squirrels, and 8' spiders. While you might be able to move the blocking operations and queue requests and keep your "main" worker threads from blocking, jdbc is synchronous. At some point, somewhere, there's going to be a thread blocking waiting for a response. It's frustrating to see so many folks hyping this and muddying the waters. Unless you write your own client for a dbms and have a dbms that can multiplex calls over a single connection (or using some other strategy to enable this capability) db access is going to block. It's not impossible to make the calls completely async, but nobody's built it yet. Yes, I know ajdbc is taking a stab at this capability, but even IT uses a thread pool for the blocking calls (be default). Someday we'll have async databa...
Read more