Top Posts & Pages
Recent Posts
My Book
Pro .NET Best Practices
Ruthlessly Helpful
Stephen Ritchie's offerings of ruthlessly helpful software engineering practices.
Monthly Archives: April 2020
First, the mental creation
Posted by on April 24, 2020
With physical things, like buildings and devices, etc. people seem to be generally okay with generating strong specifications, such as blueprints, CAD drawings, etc. These specifications are often about trying to perfect the mental creation before the physical creation gets started. In these cases, the physical thing you’re making is not at all abstract, and it could be very expensive to make. It’s hard to iterate when you’re building a bridge that’s going to be part of an interstate roadway.
What I’ve seen in the world of software, the physical creation seems abstract, and engineers writing software appears inexpensive when compared to things like steel and concrete. Many people seem to want to skip the mental creation step, and they ask that the engineers jump right into coding the thing up.
If the increment of the thing that your team is to write software for is ready to be worked on, and you have a roadmap, then an iterative and incremental approach will probably work. In fact, the idea that complex problems require iterative solutions underpins the values and principles described in the Manifesto for Agile Software Development. The Scrum process framework describes this as product increments and iterations.
However, all too often it’s a random walk guided by ambiguous language (either written or spoken) that leads to software that lacks clarity, consistency, and correctness.
Sadly and all too often, the quality assurance folks are given little time to discover and describe the issues, let alone the time to verify that the issues are resolved. During these review sessions, engineers pull out their evidence that the software is working as intended. They have a photo of a whiteboard showing some hand-wavy financial formulas. They demonstrate that they’re getting the right answer with the math-could-not-be-easier example: a loan that has a principal of $12,000.00, a term of 360 payments, an annual interest rate of 12%, and, of course, don’t forget that there are 12 months in a year. And through anomalous coincident, the software works correctly using that example. Hilarity ensues!
Unfortunately, QA is often squeezed. They are over-challenged and under-supported. They are given an absurd goal, and they persevere despite grave doubts about whether a quality release is achievable. Their hopelessness comes from knowing that the team is about to inflict this software on real people, good people, and the QA team doesn’t have the time or the power to stop the release.
What are the key things to take away:
- When the physical creation of software seems to be cheap, comparable to the mental creation of writing down and agreeing to light-weight requirements, then the temptation exists to hire nothing but software engineers and to maximize the number of people who “just write code”. In the long run, however, the rework costs are often extremely expensive.
- In the end, the end-users are going to find any defects.
- Better to have QA independently verify and validate that the software works as intended, of course, what is intended needs to be written down: clearly, consistently and correctly.
- QA ought to find issues that can to be resolved before the users get the software — issue reports that show clear gaps in required behavior.
- QA conversations with engineers ought never degenerate into a difference of opinion, which happens when there are no facts about the required behavior. Very often these discussions (rhymes with concussion) escalate into a difference of values — “you don’t understand modern software development”.
Interestingly, the software’s users are going to find the most important defects. The users are the ultimate independent validators and verifiers. End-users, their bosses, and the buyer can be ruthless reporters of defects. In fact, they might very well reject the product.
We are the Pakleds; You *are* smart!
Posted by on April 18, 2020
As one of the weary consultants on a multi-year software development project for a major lending institution I observed what became known as the “Pakled-Customer Syndrome”. The Pakleds are a race of dimwitted aliens from Star Trek: The Next Generation (TNG), which are first seen in the “Samaritan Snare” episode (summary here). They co-opt the technology of other spaceships through manipulation, brainless praise and hostage taking. Responding in good faith to the Pakled distress call the Enterprise is ensnared by the Pakled’s intractable problems and pig-headed attitude.
In the TNG episode, the Pakled are characterized by the repeating of a few simple phrases. When the crew attempts to engage them in a dialog about their distress (e.g. Is your ship damaged?) the response is always; “Uh-hunh.” Diagnostic inquiry and problem-solving are met with; “It is broken…. Can you make our ship go?”, “Make our ship go”, “Will our ship go now?” Any perceived progress is met with oddly enthusiastic and sycophantic praise; “He is smart”, “You are brilliant”; but this turns out to be unproductive support and belies their hidden agendas.
On many projects the customer can be entrenched in their own Pakled-mindset and the project is soon mired in the resulting quicksand. As organizational behavioral dysfunctions, here is what characterizes the “Pakled-Customer Syndrome”:
- Snare one: The customer takes no responsibility for understanding the problems they face: “it is broken”. Ultimately, project scope cannot be managed when there is no meeting of the minds on what are the larger tasks at hand.
- Snare two: The customer cannot participate in their own treatment. Due to many surreal disconnects too many project resources are spent teaching the customer their own business; too few project objectives are being accomplished.
- Snare three: The customer provides fake praise and misleading recognition. The project believes it is accomplishing worthy goals and that customer value is being created; it is not.
- Snare four: The customer manipulates and ties up valuable resources. The more the project starts to unravel the more the Pakled-customer latches on to your team, drawing them deeper into their dysfunction.
At the heart of the “Pakled-Customer Syndrome” are the classic differences in expectations, especially around roles and responsiblities, that lead to conflict. In addition, there are implicit and hidden agendas which must be explicated before meaningful project progress can be made.
You got to know your limitations
Posted by on April 15, 2020
Engineers must only be limited by their intellect and available time, subject to a sustainable pace. Maturity and experience are important, too.
This quote is a paraphrase of something a boss from long ago said to me. Here are the things I did to change my professional life based on this revelation, I tried to:
- Develop my intellect: Stretch my brain. Learn new skills. Acquire new knowledge. Play brain games. Start taking notes instead of always relying on my recall. Read a lot.
- Increase my available time and set a sustainable pace: Debug my personal software process (see PSP). Read some relevant books: Personal Kanban. First Things First. Learn how to say no, especially to things that are not important. Define what’s important.
- Raise my maturity level: Read some key books: Raising Your Emotional Intelligence, Working With Emotional Intelligence, I’m OK — You’re OK, Go to cognitive behavioral therapy (CBT) for my professional and personal challenges, especially to better cope with difficult people.
- Have many and varied experiences: Don’t get the same 1-year of experience for 20 years. Switch jobs. Work with people who challenge me. Don’t make the same mistake once (learn from other people’s prior mistakes). Read ahead in life by learning about other people through their biography and memoire; especially their failures.
In the end, all of these things that I tried to do I continue to do. I find them to be very helpful. I also find that I am able to be helpful to others, if I’m working to be my best.
My Book
Pro .NET Best Practices
Ruthlessly Helpful 