Re: Good programming practices and changes in requirements: how to maintain good code

You require the customer to sign off on what they want before you begin, and to sign off on the completed project if it does that, even if it doesn't do what they want! Once your customers see you are serious about this, you will have fewer cases of it. They will be more careful about what they ask for. You need commitment to follow this policy supported at the highest level, or else people will complain high enough to get around it. Yes, there will on occasion need to be emergency patches, but even then (especially then!) you can still maintain programming standards.

Dum Spiro Spero

Comment on Re: Good programming practices and changes in requirements: how to maintain good code

Replies are listed 'Best First'.
Re^2: Good programming practices and changes in requirements: how to maintain good code by chacham (Prior) on Feb 11, 2015 at 16:29 UTC
Once your customers see you are serious about this, you will have fewer cases of it. Fewer cases because they might not be continuing your employment. It probably depends on the relationship. You require the customer to sign off on what they want before you begin Even when there is sign-off, what it means is entirely a new thing. I'm on a project right now where there is sign off on multiple levels, yet almost noone knows what is happening. The customer thinks one thing, the BAs something else, the programmers have to go through multiple revisions before they get it right (according to the team lead), and the team lead overrides the customer's stated wishes by convincing them that what they want is impractical. What you want is right, but are you sure its practical?	[reply]
Re^3: Good programming practices and changes in requirements: how to maintain good code by GotToBTru (Prior) on Feb 11, 2015 at 16:36 UTC
It is completely practical - it's how it was done at Master Lock. Developers could update the version control system but could not promote code to production. Only the gatekeeper could do that (in our case, the DBA since it was mostly Oracle PL/SQL), and he required the developer to show a signed acceptance from the customer before he would do so. The customers expected the developer to demonstrate the code in front of them, and could access the development system to test for themselves, in the case of forms or reports. Dum Spiro Spero	[reply]