This is a follow-up question from an attendee of a recent TDD for Embedded C++ training course.
What exactly is a person’s responsibility for unit testing when they go into existing untested code?
Like all good questions in software development, the answer is “it depends”.
If your definition of safe, is like “no one has even been fired for choosing IBM”, SAFe may be safe. Though, you really need to consider, will it help your organization improve? I hoped that Scrum would help the world discover iterative and incremental engineering practices and principles. It seems to me, it has failed. Maybe SAFe can be different; I don’t know.
I have not spent any time looking into SAFe. I cannot make an informed opinion. I would make my opinion based on the message of SAFe and how it is being adopted. Generally, I am critical of what most Agile adoptions have become, Agile in name only (AINO). AINO adoptions leave developers feeling like they are being micromanaged and pressured to do poor work.
Being one of the people that participated in the creation of the Agile Manifesto, I find myself very disappointed by the reaction of engineers to the question “Are you practicing Agile?” Their shoulders drop. They start to slowly shake their heads. They mumble; they grumble. They tell me agile is horrible. I ask why. Reasons I head most often are:
Continue reading
Kent Beck told me years ago, if the code does not need to work, then there is no need to test it. He continued and observed, why bother writing it if it does not need to work. Since hearing that and discovering how frequently I make coding mistakes, I want thorough tests.
Maybe you are asking yourself “I’ve got integration and system tests, why do I need unit tests?”. The answer is simple, simple math.
Continue reading
I’ve heard people say that software should be like building. You make a plan; buy the materials; and build it. Would remodeling be like new construction? Kind of. You make a plan, find a contractor, agree on the specs, order materials, demo (demolish) the unwanted parts of the building and build it out. Simple step by step.
Does it go that way?
Continue reading
The Boy Scouts have a rule: leave the camp cleaner than you found it. This does not mean that all the trash has to be cleaned up now, but you can’t let it get worse, and it must get at least a little better. In Bob Martin’s book, Clean Code, he asks, “What if code got a little better every time you change it?” I’ll answer it: the industry would not find itself in the mess it’s in. The industry norm is for code to incrementally worsen with each change.
Much of the time, following the Boy Scout Rule won’t be hard. It’s an incremental strategy. It’s easy to start and easy to sustain. Here are some typical challenges and ideas on how to be a Boy Scout.
One important realization on the journey from a BDUF approach to an iterative and agile approach is that design is never done. Designs evolve. The waterfall emphasis has been to unnaturally try to control software physics by imposing requirements freezes and burdensome change control. The process of developing software is part science and part creative. You are applying science toward the invention of something. Design is capturing knowledge both about what the end user need is, and one solution to that need.
Continue reading
Constrained Memory is the reality for many embedded developers. Running tests in the development system won’t suffer the same memory constraints found in the target. Here are a few things to help TDD in constrained memory situations.
Continue reading
Embedded software has all the challenges of “regular” software, like poor quality and unreliable schedules. It is just software with some additional challenges. The additional challenges do not disqualify TDD for embedded. TDD even helps with some of those uniquely embedded challenges.
Continue reading
A unit test harness’ job is to provide: