Authority and Responsibility are the same thing

September 20, 2018

Inspired by Ron Jeffries‘ “Manager Responsibilities” article, I responded…

I like that you gave the word “Responsibilities” such prominence. While in some ways I have been quite critical of “management” lately, I think that my issue lies more with the question of authority and responsibility.

I think that…

Authority and Responsibility are the same thing.

And that this is important.

I think that those who try to delegate or impose responsibility on others, while denying them the necessary authority to act are frauds.

And I have seen quite a few people over the years misusing agile concepts to do that. “This is SCRUM.” they say, “And you take full responsibility for your commitment to deliver all these things by the deadline (… regardless of anything I or others do to you). This is ‘your commitment(that I’m imposing on you).” And (sometimes) then, they actively sabotage your efforts and yet still insist on holding you “responsible” for “your commitment.” I find such behavior fraudulent. You give both or you take both. You can’t give one and keep back the other.

To clarify…

If you use your authority, then you are taking responsibility.

When you intervene and tell your people to stop doing this, and to do that instead… When you tell people to stop doing things the way they think is best, and do things your way instead… Then you have used your authority to override others. And by doing so, you have taken responsibility for the results. No matter how much you might try to deny it. No matter how much you might try to appeal to “their professionalism” or “their job title” as reasons why they should give up everything and possibly “do the impossible” to “deliver on their commitments,” you have used your authority in ways that affect the outcome, and so you are responsible for that.

When I am working as a leader or manger, I strive to keep that in mind: That it’s impossible to delegate responsibility without also delegating authority. And when I use my authority, I am taking responsibility.

I have found that that works well. And I wish that others would also keep that in mind, and do the same.


RE: 20 Tips for becoming a better programmer

May 16, 2013

Regarding “20 Tips for becoming a better programmer”…

Yes, these are some good rules. And an expert programmer not only knows the rules, but also knows when to violate them. Because the rules often conflict. And to achieve the best result often involves trade-offs and compromises.

“1. There should be only ONE single exit point to each method (use if-else whenever needed).”
This is a great structured programming rule. And in the time when individual functions often spanned multiple printed pages, it was a practical necessity – for those who wished to preserve their sanity.

But even and especially with excessively large functions, “guard clauses” at the top of a function that exit quickly when the input parameters are bad or have extreme “special case” values makes sense.

And in these days of object-oriented programming, methods with more than a few dozen lines are questionable. With short methods or methods with an extremely simple repeating structure (switch-case), it can make a lot of sense to have multiple exit points (return statements).

“2. When using if-else, make sure to place the SHORTER code snippet in the if:”
But code that says

If not X then
Do A.
Do B.

Will confuse people and rot their brains. When does it “Do B.”? It does B when “not not X”, of course! “Ahhhhhhh! My brain hurts!!!” say most maintenance programmers.

It’s generally a bad idea to use “negative logic” in an if statement that has an else clause. It will confuse people.

“3. Do NOT throw exceptions if you can avoid it, it makes your code MUCH slower, if you feel like throwing something and then catching it – go play ball with your dog. If you don’t have a dog get one – they’re awesome!”
First, get a cat. Cats are way more cool. ^-^

Yes, what he says is true. There is a time and a place for exceptions. They are for “exceptional” conditions – things that have gone wrong. One hopes that this does not happen very often. Exceptions should *NOT* be used for flow control in business logic.

And exceptions are just about the only way to deal with some circumstances. Such cases may be an indication of bad design in the framework you’re using. Exceptions are just about the only way to stop processing in a SAX parser when you find that there is no good reason to read and process the rest of the file.

“4. Do NOT try to do many things on the same line – when you’ll get an error – it will be harder to debug, example how to NOT write your code:”
Generally true – particularly with complex expressions and function/method calls.

“5. Look for code pieces that look the same and if you find any – REFACTOR your own code!”

“6. Proper names are a MUST. If you’re not sure, meditate on it for another minute. Still not sure? ask your colleagues for their opinion.”
(Honestly, I don’t know what he’s talking about here. “Proper names?” Like “Jeff Grigg”?)

[Edit:  Oh! So he means “meaningful names” (for classes, methods, variables, etc.).  Why yes, of course.  (And thanks to for the clarification.)]

“7. Whenever you can use HashMap instead of List/Queue – use it!”
And something that I see faaaaaaaaaaaaaaaaaaaaar more often:
Would you people please ***STOP*** using ArrayList when what you really need is a Set?!? The List interface really should not include the “contains” method. If you’re using the “contains” method on List objects, you’re almost certainly doing it wrong. Try again. :-[

“8. If you can use caching instead of I/O (usually DB) – use caching”
Caching is a highly valuable tool. But it’s not a silver bullet. Be aware of its uses and limitations. There are times when you must not use it. An expert will recognize these situaitons.

“9. If you can parse it using regex – use regex”
Generally, people should use regex a lot more than they do. But as with any tool, it can be abused. (See rule #10, below. ;-)

“10. Do not parse HTML using regex”
Regex may be involved. But honestly, there are a crazy number of most excellent XML parsers available for free in Java.

A competent craftsman has good tools and uses them with skill.

“11. Print to Log.”
True. Beginners and hackers dump text all over the place with System.out.println statements scattered through the code.

“12. Use stackoverflow – not only for asking questions! take a few minutes, every day, and try to answer questions – you’ll be surprised how much you’ll learn from it!”
True. And others. Be an active part of your community. It will do you and others a world of good.

“13. A rule of thumb: if your method is over 50 lines – split it. If your class is over 500 lines – split it. If you think you can’t split it – you’re doing something wrong.”
Double-plus true. ;->

‘14. Writing a code which is “self explanatory” is great but also very hard, if you’re not sure how “obvious” your code is – use code-comments.’
“15. When writing code comments always assume that the reader doesn’t know what you’re trying to do. Be patient & explain. No one is going to *bug* you because your comment was too long…”
Comments are a code smell.
The need to write comments to explain what the code doesn’t show is generally an indication that your code could be improved to be more readable. And then you would not need the comments. The one clear exception to this is comments that explain why the code that does what it does. The code itself should clearly express what it does and how. “Why” comments are very useful.

And having said that, I have to agree that comments are often the best and quickest way to add meaning to the code. One doesn’t always have sufficient time or inspiration needed to make the code 100% clear.

“16. You want to improve? read books, blogs, technical online newspapers join relevant groups on Linkedin, update yourself with the latest technologies, go to conferences, got the point?”
17. Practice makes perfect: solve code-challenges, join hackathons, go to meetups etc
…and insightful wise postings like this one. ;->

“18. Choose one IDE and study it carefully, make sure you know the major features. Tune-up the keyboard shortcuts – it will make your workflow smoother.”
Strive to learn the keyboard shortcuts for things you commonly do.
(And, more generally, automate tasks that you do often!)

“19. Whenever you find a bug, before you fix it, write a unit-test that captures it. Make sure it does.”

‘20. Don’t get lazy – RTFM’
‘We’ll finish with two quotes:’
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
– Brian Kernighan
“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”
– Rick Osborne
‘Be Sociable, Share!’

There’s a lot of wisdom in there.
(And I do know where you live. ;-)

My Experiences with Requirements Traceability

August 3, 2011

With some positive feedback on my post on the Yahoo Test-driven Development group, I thought I’d post my comments here, to make them more accessible:

— abrar arshadwrote:

Yeah I know requirements traceability has always been related to formal requirements specification and in agile with don’t have formal documentation. … For instances, how do you know where to make changes if your client wants you to change a feature which already has been developed. There is a chance that changing one feature might effect the others as well. …

I was involved in Document-Driven approaches for quite a few years before joining the XP community. “Requirements Tracability” was always a promise of the document-driven approach, used in part to justify its high cost. But honestly, I have never seen it deliver as promised:

Requirements tracability advocates say that it will show you where to make a new change, and that it will highlight conflicting requirements. I have never seen this happen in practice.

Consider this example: We have a system that is computing hourly pay in several divisions at several union plants. There is a fair amount of hard-coded conditional code. We just renegotiated the overtime rates for one of the divisions at two plants.

For requirements tracability to be useful, it has to be easier to find the original requirements for these divisions and to trace these requirements down to code than it would be to find the code directly. And to see conflicts, one would have to go from all the requirements that are relevant to the code back to the requirements documents — and then somehow figure out what to do with a whole bunch of requirements statements — to see if they conflict or overlap in any way, and how to resolve the issues.

Generally, in practice, it’s pretty easy to find the relevant code, even without any external requirements documentation. It’s easier to find the code than to trace through a tangled mess of requirement number references.

And to make the change… Add or change tests. Then change the code so that it passes the tests. If there are conflicting requirements, other tests will fail. You’ll look at the other tests and probably learn something. Sometimes it’s a technical issue, easily solved. Sometimes it is a real conflict in the business requirements. In that case, you will probably have to go back to the business requirements and maybe to the people who specify them to resolve the business issue.

So requirements tracability is not only costly and quickly out of date, it turns out to not be very useful. About the only good thing I’ve seen requirements tracability do is to serve as a checklist of all the things the system must do: When they’re all checked off, then you have reason to believe that the system does everything that’s been requested. User stories with automated acceptance tests also do this — with much higher justifiable confidence levels.

What if your bug crashes the Mars rover?

January 23, 2011

In “This Developer’s Life” podcast “1.0.3 Problems” mentioned on Scott Hanselman’s blog

Regarding the “1.0.3 Problems” comments about how bad it would be to have written “the bug” that trashed a Mars rover:  I don’t think we have to speculate too much about hypothetical situations.  We have the Hubble telescope mirror, for instance:

and the Mars orbiter thing too:

“Bummer, dude” is one possible response.

Lemp Haunted Mansion Tour

April 16, 2010

I went on the Lemp “Haunted” Mansion tour on Thursday night, led by members of a “supernatural investigation” group. A little over a dozen of us from the Saint Louis skeptics group went together on the tour. As skeptics, we had plenty of flashlights and cameras of our own. And we also played with two of our host’s infrared cameras.

I found the indoor aviary room (downstairs; part of the restaurant) most creepy, due to the dark painted outdoor scene. Unlike in my previous visit to the mansion, the gift shop was not freakishly cold this time. (The weather was different; previous trip was early winter, this trip was after a week of quite warm weather.)

It’s a nice bead and breakfast place: The two large 2nd floor rooms are very nice. I liked the cozy and modern bathroom in the Elsa Lemp Suite. I’d like to stay there.

Being a caver, I am of course very interested in the cave under the mansion. Here is a very good site describing the cave:

Looks like when I stood on the 3×3 ft wood cover in the basement, I was probably standing right over a nasty 34 ft drop into the cave. Nice. Good thing I didn’t jump up and down on it. ;->

Here is a much better map of the cave than the one shown in the Lemp Mansion gift shop:

(And the pool is properly marked on this map.)

Postcard from the old Cherokee Cave public tours shown at the bottom of this page:

I have a VHS video tape that includes a legal visit to Cherokee Cave (and also the storm drains under Forest Park and the River des Peres. It’s a 50-minute KETC Channel 9 special called “Under St. Louis”, “St. Louis Chronicles”, 1998. “Produced in cooperation with the Missouri Historical Society.” I think it was a bonus sent to KETC members. (See it pays to be a contributing member of your local public TV and radio stations! ;-)

The eleven minute portion about Cherokee Cave is available on You Tube here:

Here’s a blog, with good pictures, of someone trespassing into the cave, a practice that is ILLEGAL and DANGEROUS!!!

Now Senior Technical Integration Consultant at Guidewire Software

January 22, 2010

I just accepted a position as a Senior Technical Integration Consultant at Guidewire Software, starting the first of next month.

Express-Scripts Layoff

January 3, 2010

Yes, I was part of the ESI layoff of 90% of contractors last month. I am working with Advantage Consulting and partners to find a new position.

As always, I am particularly interested in highly challenging and rewarding opportunities. And I am willing to take on a heavy travel schedule and to relocate.