I'm a late convert to TDD and unit testing in general, but I'm wondering if/when a slide back into RAD is warranted. Take a (very) simple CRUD, for instance, something we all know can be created in Delphi with very little effort. Are Delphi developers choosing to abstract all of that data access so it can be unit tested, or do they dip back into RAD?
I'm a late convert to TDD and unit testing in general, but I'm wondering if/when a slide back into RAD is warranted. Take a (very) simple CRUD, for instance, something we all know can be created in Delphi with very little effort. Are Delphi developers choosing to abstract all of that data access so it can be unit tested, or do they dip back into RAD?
I guess it boils down to...does "always write testable code" generally translate to "never use RAD" for most TDDers?
Thanks.
I guess it boils down to...does "always write testable code" generally translate to "never use RAD" for most TDDers?
Thanks.
My job includes to describe processes for a programming team that is larger than what most consider max size for a scrum team. The question is always, how do you enforce qa on a large organisation? In our case, ISO 13485 and IEC 62304 have been good pals. They add overhead but also seriously improve the ability to create the right solution in the first attempt. Complex things are now much easier to do whereas simple things have gotten more overhead. RAD is permitted for non-critical code whereas critical code must have detailed design requirements that are verified by others. With Delphi, critical and noncritical code can be mixed in an exe file because of the absence of a global namespace. You just need to define a rationale for why the noncritical code doesn't mess up the critical code. Unit testing is one of multiple solutions for verifying critical code and can also be applied on noncritical code. RAD can be used on noncritical code but for critical code, you probably need things to be easier to verify, than having all your logic in GUI components.
ReplyDeleteLars Dybdahl that is very interesting, particularly because we are trying to move to an SDLC that includes more in terms of incorporating security because part of our application processes credit cards, and must be approved under PA-DSS.
ReplyDeleteISO 13485 is very similar to ISO 9000 except that ISO 13485 requires that the top management must be made responsible for the safety of the code that the programmer writes. This adds some extra complexity, which is why IEC 62304 was invented. Both of these were invented for medical devices, there may be similar standards for other business branches. Other than that, my experience is, that a great QA system consists of procedures that follow the standards, in a best-practice way, a set of best-practices for making decisions and documenting, training and tools. Unfortunately, we ended up making our own tools because it was more efficient than any commercial product out there, but we had a great consultant on introducing our QA system. The costs for this transformation are significant, but in our case, I assume that it pays back in 1-2 years because of increased efficiency. But that really requires that you do it right - doing it wrong can clog up the entire organization. So my recommendation is, that if you are unsure whether the organization can handle a new QA system, just copy the best ideas.
ReplyDelete