Being pressured to GOTO the dark-side

Question

We have a situation at work where developers working on a legacy (core) system are being pressured into using GOTO statements when adding new features into existing code tha

Answer 1

The underlying problem here seems to be that you have 'analysts' who describe, presumably necessary, functional changes in terms of adding a goto to some code. And then you have 'programmers' whose job appears to be limited to typing in that change and then complaining about it.

To make anything different, that dysfunctional allocation of responsibilities between those people needs to change. There are a lot of different ways to split up the work: The classic, conventional one (that is quite likely the official, but ignored, policy in your work) is to have analysts write a implementation-independent specification document and programmers implement it as maintainably as they can.

The problem with that theoretical approach is it is actually unworkably unrealistic in many common situations. In particular, doing it 'properly' requires employees seen as junior to win an argument with colleagues who are more senior, have better social connections in the office, and more business-savvy. If the argument 'goto is not implementation-independent, so as an analyst you simply can't say that word' doesn't fly at your workspace, then presumably this is the case.

Far better in many circumstances are alternatives like:

1. analysts write client-facing code and developers write infrastructure.
2. Analysts write executable specifications which are used as reference implementations for unit tests.
3. Developers create a domain specific language in which analysts program.
4. You drop he distinction between one and the other, having only a hybrid.