This is William Nichols's Typepad Profile.
Join Typepad and start following William Nichols's activity
Join Now!
Already a member? Sign In
William Nichols
Recent Activity
Steve Forbes gets it wrong in almost every detail, yet he is more or less right on the big picture issue of government as the decision maker on effectiveness. Richard J. Ablin argues 1) that the original decsion to recommend routine screening was wrong 2) panels, such as a government panel, are and will be influenced(or even captured) by those with a financial interest 3) decisions should be made with local knowledge (e.g. family history, baselines, medical history) Now, your point that Steve Forbes argued badly (very badly indeed) is correct. The rhetorical shot about "socialist", however, is an unnecessary cheap shot. He said that health care needed more free enterprise without specifically endorsing your alternative. The deconstruction is stronger without the impled ad hominiem accusation of hypocracy.
http://xkcd.com/895/ ( analogies ) No pun intended, but that definition of "complex" seems surprisingly simple and it does cause me to think about the problem in a different way. The double pendulum is fully deterministic, but in some regimes, difficult (or practically impossible) to calculate with precision for arbitrary times in the future. A complex problem is of a somewhat different character.
Toggle Commented May 10, 2011 on Complexity versus Simplicity at Herding Cats
1 reply
I did a talk at the Pittsburgh SPIN last fall on this subject. http://seispin.wikispaces.com/file/view/PITT-SPIN-Sept-10-EV-in-SW-Projects-PSP.pdf I address some of the common objections Software development work is hard to estimate with sufficient accuracy. You can’t get an accurate progress report from a software developer. Until the software tests successfully we don’t know that we are done. Software is iterative, work is revised a number of times before complete Software project have imprecise requirements, scope isn’t fixed
Toggle Commented May 6, 2011 on Clarity of Purpose at Herding Cats
1 reply
Dan, Absolutely correct. Please excuse the double negative, it doesn't disprove the hypothesis. Neither does it provide any credibility. And too often, there is no testable hypothesis. In my experience, the best researchers were very creative in asking the right questions. They might be very biased, but they could always ask challenging questions.
1 reply
"Emergent" architecture leads to the "refactoring iteration(s)". I expect as you apply EVM to development projects this will be more exposed. Though I doubt you would allow an "emergent" architecture in the first place. Architecture has global consequences and there are some properties that must be built into the system. I have a single data point for a non-trival system where we have measured the architectural investment on a system that architected up front. It only delayed implementation tasks by several weeks and consumed a total of about of 12% project effort. There was essentially no required architectural rework on the project, and no significant need for refactoring rework. The work was incremental and implemented with self directed teams. Our contribution was a joint effort from the Architectural team and the TSP team. It will be discussed at SATURN and it should become subject of a case study (a real case study, not a non-fiction novel) We have a lot of detailed data on cost and rework.
Toggle Commented May 5, 2011 on Want To Do Architecture Right at Herding Cats
1 reply
Glen, Unfortunately, as you've documented in other posts, some don't have a "theory" just hand waving.
1 reply
Funny thing is that I canceled my subscription to Dr. Dobbs a couple years ago. I was very irritated by one of the "thought leaders" drawing global conclusions from an unscientific survey by ignoring the modal response of "don't know". In fairness, he included a link the survey monkey where I could see the raw data. Separating fact from fiction had just become too hard in that venue. It is hard to draw good empirical conclusions in software engineering. Real experiments are hard or maybe impossible to get enough samples for generalization. It is possible, sometimes, to insert some quasi-experiments (Donald Campbell calls them queasy experiments) Case studies are more common, but very few look like they come close to the standards of Yin. We, as a profession, need to get a lot better and can start by calling out those who abuse the numbers. Everyone else should get a more polite and constructive critique. We need better theory, critical analysis, and above all, empirical validation that challenges our models. It would be nice to see the thought leaders examine their own work more critically. "how do you know?", "what are the assumptions?" "what exactly are the propositions?", "what are the threats to validity?", "what are plausible alternative explanations?", "how could you test the alternatives?" It's a lot of work, and if someone can't do at least some of it for me, I won't be bothered.
1 reply
BTW, Yes there are scenarios where someone just isn't trying, it might be passive or active resistance. I just don't start with that assumption and I'd rather get them to come to that realization themselves.
Toggle Commented May 2, 2011 on Leadership and Management at Herding Cats
1 reply
Glen, You bring a great example, now let me explain what I mean when I say "trying harder" would not help. Even if well intentioned, trying may not work without an action plan. I will ignore, for now, the possibility I have an unusual circumstance that implies a change or exception to the system or that I can satisfy the current system, but only at great expense. When the answer seems to be "Try harder" , follow up by asking "doing what?" What you are doing isn't working, will you do more of it faster and harder? Or will you change in some way? Yes, effort and commitment is an issue here. But "Try harder" is not specific enough. It must be coupled with an action plan on doing something differently. In this example, we need data to be entered daily, we need all receipts to be collected and saved in a retrievable way. What changes in practice or habits might help? So why is this a problem? What could you do that makes this less of a problem? As a notional example, I had to do something similar for travel reimbursement. My personal process now includes that I pack a business envelope on which I've drawn some lines on the side. Into this envelope I place each relevant receipt, and on the side of that envelope a one line summary (date, purpose, amount). If there is no receipt, I note NR on the summary. I tried this and it works well for me in my environment. My problem is different from your example, but the key is that I determined what I would do differently and how I would do it, mindful that I must satisfy the needs of the system.
Toggle Commented May 2, 2011 on Leadership and Management at Herding Cats
1 reply
David, Yes, that wheel has been invented and reinvented many times. We (that is my TSP team) use a defect review script that walks through where the problem was injected and all activities through which it passed undetected. At each step the participants (SME only) ask if the process could have detected this issue, if not why not and how it might be changed, if it could and failed, why did it fail. The outcomes are process improvement proposals (PIP) that we can later evaluate for process change. "Try harder" is not an acceptable PIP. Training, changes to scripts, checklists, or environment that make the process easier to execute or less likely to miss something are what we are after. As a practical matter, the "try harder" is too often the outcome of "Lessons learned" I've been involved with. That is not very helpful because it is not precise, directly actionable, or measurable. Moreover, "try harder" comes close to assigning blame. Blaming someone is less effective for change than finding what "we" can do differently. How can "we" make process execution more robust.
Toggle Commented May 1, 2011 on Leadership and Management at Herding Cats
1 reply
What you describe sounds fine for single point broadcast, but doesn't address conditions where response is needed, others must share information or organize offline one-on-one exchanges.
Toggle Commented Apr 30, 2011 on O Group update at The Hard-Nosed Project Manager
Charlie is on my "must read" list."Correlation does not imply causality" or (some variant)Is simple and a point to live by, but it doesn't operationalize the difficulty. The longer quote acknowledges the problem and the next obvious step, hypothesizing (or rationalizing)and asks "what next?". How do you test your model or hypothesis? There are reasonable scientific and engineering approaches short of double blinded randomized studies, but the methods are not widely used or understood by the community. In it's place has been a lot of notional hand waving and appeals to authority. There are exceptions, I'd like to see sound methods and analysis become the rule.
Toggle Commented Apr 25, 2011 on Quote of the Day at Herding Cats
1 reply
I like this version of the talk. http://www.youtube.com/watch?v=u6XAPnuFjJc I've been meaning to pick up his book, "Drive".
Toggle Commented Apr 24, 2011 on 21st Century Motivation at Herding Cats
1 reply
Glen, In your excellent list of ways a project could go into the ditch, you didn't list a technical problem. When things go bad, I suspect it's more often a non-technical problem than a technical problem. For that matter, in the technical solution, it's more often a non-functional than a functional problem. One can usually get a code or a product to do something, but fast enough, cheap enough, changeable enough, secure enough, safe enough, reliable enough.... That's another story. And outside the product, it's all non-functionals.
1 reply
One can learn quite a bit reading that book by Lakoff and Johnson. But an unintended lesson I took away is that even a good case can outkick it's coverage. I can list numerous examples of "metaphors" that are now merely figures of speech, "coming to a head", "pig in a poke", "let the cat out of the bag". "balls to the wall". By claiming that metaphor is the foundation of conceptual thought, Lakoff trivializes the underlying abstraction. Many of us, upon hearing a metaphor convert it into a simile, abstracting the like qualities while recognizing the essential differences. "is a" is a literary device, not a model nor an instantiation of a generalization. It is our ability recognize differences and appreciate irony that gives the twisted language in "1984" its impact. Those that neglect this can be made to look foolish. Unfortunately, we have in many cases a failure to engage in abstract thinking(or perhaps the user of the metaphor as simile doesn't understand the abstraction)I label this impairment "Abstraction Deficit Disorder", or ADD.
1 reply
here we go, http://it.usaspending.gov/faq-agencies I must have missed this in the evening. %CostVariance Cost Rating (0-10 scale) 0% 10 10% 7 30% 3 >50% 0 This is one sided, but there may be ways to get real distributions.
1 reply
I cannot find any description of "needs attention" or "normal". Where is this documented?
1 reply
I had quite the discussion with K at Eight2Late about metaphor not long ago. Since Lakoff, many take it more seriously as a marketing device. Whereas simile makes the concept notional, metaphor sometimes implies a more concrete relationship. I think of metaphor as a literary device, but Lakoff argues, with some effectiveness, that it is a foundation of thought. Even if that is true, sell someone a "pig in the poke" or "jump the shark", and you become a "laughing stock" when the "cat is out of the bag".
1 reply
I hit the reply too soon. I know people have seen it, but they weren't seeking us out to talk about it. I recall speaking to a group of Col. level Army people in January, oddly they didn't mention that document, but they clearly had something on their mind. The topics that came up repeatedly 1) there is nothing in the acquisition process preventing agile from being used 2) but there are problems actually writing a contract because of the "arms length" requirements 3) I told them more or less, let vendors use it "inside their work package" 4) they wanted to know how to tell if the vendors actually used "agile" among other things. I found out about that acquisition document from you. Very soon after. Suddenly it all made sense. A colleague who works with one of the ASP people (not Dan) told me that they are aware. I suspect it probably was in the works when Dan Burton and two others from ASP did the agile in the DOD technical report released in Sept or Nov. Regardless, I will make some inquiries after returning from Uruguay.
1 reply
I don't know. When I get home I can try to find out.
1 reply
That's a difficult question to answer. I can't even pretend to see more than a small part of this elephant. I know that some in the leadership are aware of bigger problems. Cynthia Dion-Schwarz of ODE spoke at length of her frustration with the acquisition process, especially on how to assess projects out there on the technology edge for feasibility at various stages. Perhaps DAU or someone in our Acquisition Support Program has the combination of credibility and contacts to make that case.
1 reply
Yes, they are working on selling the concept to agilists. Under appreciated, in my experience, is the need for an architecture foundation for agile to be successful. I have a draft of a course based our on a pilot discussed in this presentation. Rod and a couple others are focused on the Architecture side. http://www.sei.cmu.edu/tspsymposium/past-proceedings/2010/TSP_Plays_the_ACE.pdf
1 reply
Of your observations, bottom up and maintaining the agile within the work package seems inevitable. It's an obvious solution. I'm not so sure about the Architecture though. Capers Jones data doesn't offer much optimism for scaling to real large projects or programs. It strikes me, notionally, as the problem small businesses have when growing. Many falter at a certain size because they cannot apply the next level/layer of management. I think there may be two walls, architecture and project/program governance. I will be interested to see how they address these.
1 reply
Glen, Thanks for that link, I was completely unaware it was out there. I watched the rest of them too. Rod's colleague Ian is now a certified instructor. Unsurprisingly, he did the best design verification lecture I ever saw. Rod is right that the developers of PSP can undervalue the contribution of tools, but that is fairly easy to fix. The greater danger I see every day is relying on the tools as a substitute for sound engineering practices.
1 reply
“I understand your requirements, I will do my utmost to meet it, but until I make a plan, I can not responsibly commit to a date” Watts Humphrey
Toggle Commented Apr 2, 2011 on Plan First, Then Schedule at Herding Cats
1 reply