Two of his posts stood out because they discussed how to approach a technical system and think of it as a planned response system. He goes on to define system responsibilities, essences, events, and obligations.
The definition a system’s essence makes no mention whatever of technology inside the system, because the system’s essential responsibilities would be the same whether it were implemented using software, magical fairies, a horde of trained monkeys, or my brothers Glenn and Gregg wielding pencils and stacks of index cards.In a second post in the series, he goes on to discuss the anatomy of responsibility further. Both are good reads, and I encourage you to check them out.
Staying on the Dale Emery kick for the day... I also enjoyed his post about "testing as an information service." He focuses on the quality assurance and testing team roles and how they affect the surrounding team.
Testing is an information service. The point of testing is to inform stakeholders about the system. This is not a new sentiment, nor does it originate with me.He goes on to tell a story about one student in his class and how he realized the goal of his role is not to rub developer's faces in found bugs, but to inform the team and stakeholders equally of what is broken AND what works as expected. Testing is a litmus test, not a contest.
hmmm... I'm going to repeat that last one again and stake claim to the quote... "Testing is a litmus test, not a contest."