I used to say for over 15 years, put the Analyst back into Analyst/Programmer. This was when many jobs where advertised as Analyst/Programmer, but the Programmer never really did any meaningful analysis. It was mainly confined to the act of writing code not so much about the understanding of requirements.
The reason it fell into disuse is probably correct when you look at the traditional ways software was produced. Another reason could be the cognitive load required between swapping out of coding and understanding requirements. This a more like an excuse rather than looking for causes.
I’ve now come to say put the Analyst into Analyst/Programmer. It was never really there in the first place. A programmer can and should have valued input from the beginning of the software production process. That does also mean being a nice person and maybe strengthening into areas not so familiar like talking to customers – it’s a communication process as much as a technical process 😉
Inspired by this talk from Martin Fowler this year that I feel aligns with this ideal, I’ve included the following call to arms that I now start my Agile Programming course with, which is to be released soon. I hope to sharpen it up a bit more. You can have input into it if you like. Here’s a start:
As programmers we are more than just code monkeys. We are motivated to create value for our customer, so we should be on board with everything including:
- Being able to speak to our customers to learn the domain we are working in
- Being able to seek clarification from anyone be it Business Analysts, Customers, Product Owners, Testers or anyone else
- To question anything that we have concerns about
- Expect to have a meaningful input into understanding requirements
- Expect to inject innovation and have it considered
Over to you. Admittedly there is some work to do to unravel decades of silo based work practices.