Was I wrong about Analyst Programmers?
-
I've been in software development a long, long time. And I've always believed that the Analyst Programmer role was the best option, when it comes to getting things done. I should qualify that: - an Analyst Programmer needs to have a good understanding of both the business and the technology/systems - by "best", I mean most efficient. This was borne out a couple of jobs back, when the software development team I was working in, consisted of experienced developers - and Analysts who had less understanding of the business, (than the developers), and no understanding of the technology/systems. Invariably, on receipt of a spec, developers would need to: identify actual requirements by talking to users; correct half-baked ideas that weren't in line with the technolgy; and devise their own testing. Analysts were actually making the whole job more difficult. Most - if not all - of the senior developers would have provided a quicker/better solution if they had done the analysis and spec work themselves. Yeah. Analyst Programmers. Don't get me wrong. There are developers who shouldn't be let near a spec... or a user... and, in some cases, a keyboard. But they are the exception. But there is one "blind spot" that a developer needs to overcome before taking on any sort of analysis role. Fast forward to today. I'm currently doing a few small jobs for a big company that has a small development team... and a "Solutions Architect". The Solutions Architect has been with the company for many years; started there as a programmer; has an in-depth understanding of both the business and the technology; and produces all the specs. But... His mind-set is 100% that of a developer He has that "blind spot". And it's right there in his job title. What I want from a spec is a clear explanation of the problem - ideally with examples, that can provide the basis for testing. Want I don't want from a spec is just a solution. It's an easy trap to fall into. Developers tend to be fixers/solvers of problems - i.e. solution providers. If you can't explain the problem - the "why we need to do this" - you shouldn't be producing specs. Remember... this just MHO. :)
-
I've been in software development a long, long time. And I've always believed that the Analyst Programmer role was the best option, when it comes to getting things done. I should qualify that: - an Analyst Programmer needs to have a good understanding of both the business and the technology/systems - by "best", I mean most efficient. This was borne out a couple of jobs back, when the software development team I was working in, consisted of experienced developers - and Analysts who had less understanding of the business, (than the developers), and no understanding of the technology/systems. Invariably, on receipt of a spec, developers would need to: identify actual requirements by talking to users; correct half-baked ideas that weren't in line with the technolgy; and devise their own testing. Analysts were actually making the whole job more difficult. Most - if not all - of the senior developers would have provided a quicker/better solution if they had done the analysis and spec work themselves. Yeah. Analyst Programmers. Don't get me wrong. There are developers who shouldn't be let near a spec... or a user... and, in some cases, a keyboard. But they are the exception. But there is one "blind spot" that a developer needs to overcome before taking on any sort of analysis role. Fast forward to today. I'm currently doing a few small jobs for a big company that has a small development team... and a "Solutions Architect". The Solutions Architect has been with the company for many years; started there as a programmer; has an in-depth understanding of both the business and the technology; and produces all the specs. But... His mind-set is 100% that of a developer He has that "blind spot". And it's right there in his job title. What I want from a spec is a clear explanation of the problem - ideally with examples, that can provide the basis for testing. Want I don't want from a spec is just a solution. It's an easy trap to fall into. Developers tend to be fixers/solvers of problems - i.e. solution providers. If you can't explain the problem - the "why we need to do this" - you shouldn't be producing specs. Remember... this just MHO. :)
I know a guy who's completely into the technology, but has no eye for businesses. He'd send out emails to customers saying stuff like "When you click the button we do an AJAX call and in the POST we store the entity in the database through a foreign key relation." Well, maybe not that bad, but you get the idea. Luckily, I checked his emails before he'd send them and it simply didn't occur to him to simply say "when you click the button we store the product." That was way to simplistic according to him. I once had a customer who didn't want to speak to a coworker anymore exactly because that coworker talked like that and the customer didn't understand him and wasted his time. Because I've worked with many developers who are like that I'm for the duo. An analyst, preferably one who also has technical knowledge, and a developer, going out to talk to the customer together. They can both see how the customer works and what they do and after that the analyst can work it out, but the developers isn't blank either. It's also good for the users and developers to get to know each other because it becomes easier for either of them to send and email or just pick up the phone. Of course there are also many companies who shudder in fear of the idea that a developer and a user are in direct contact with each other.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I've been in software development a long, long time. And I've always believed that the Analyst Programmer role was the best option, when it comes to getting things done. I should qualify that: - an Analyst Programmer needs to have a good understanding of both the business and the technology/systems - by "best", I mean most efficient. This was borne out a couple of jobs back, when the software development team I was working in, consisted of experienced developers - and Analysts who had less understanding of the business, (than the developers), and no understanding of the technology/systems. Invariably, on receipt of a spec, developers would need to: identify actual requirements by talking to users; correct half-baked ideas that weren't in line with the technolgy; and devise their own testing. Analysts were actually making the whole job more difficult. Most - if not all - of the senior developers would have provided a quicker/better solution if they had done the analysis and spec work themselves. Yeah. Analyst Programmers. Don't get me wrong. There are developers who shouldn't be let near a spec... or a user... and, in some cases, a keyboard. But they are the exception. But there is one "blind spot" that a developer needs to overcome before taking on any sort of analysis role. Fast forward to today. I'm currently doing a few small jobs for a big company that has a small development team... and a "Solutions Architect". The Solutions Architect has been with the company for many years; started there as a programmer; has an in-depth understanding of both the business and the technology; and produces all the specs. But... His mind-set is 100% that of a developer He has that "blind spot". And it's right there in his job title. What I want from a spec is a clear explanation of the problem - ideally with examples, that can provide the basis for testing. Want I don't want from a spec is just a solution. It's an easy trap to fall into. Developers tend to be fixers/solvers of problems - i.e. solution providers. If you can't explain the problem - the "why we need to do this" - you shouldn't be producing specs. Remember... this just MHO. :)
There are a lot of confusion between job titles and what they should actually do. The Analyst Programmer will/should be responsible of the technical aspect on how to implement what the business analyst wants (after talking to the clients... )
CI/CD = Continuous Impediment/Continuous Despair
-
I know a guy who's completely into the technology, but has no eye for businesses. He'd send out emails to customers saying stuff like "When you click the button we do an AJAX call and in the POST we store the entity in the database through a foreign key relation." Well, maybe not that bad, but you get the idea. Luckily, I checked his emails before he'd send them and it simply didn't occur to him to simply say "when you click the button we store the product." That was way to simplistic according to him. I once had a customer who didn't want to speak to a coworker anymore exactly because that coworker talked like that and the customer didn't understand him and wasted his time. Because I've worked with many developers who are like that I'm for the duo. An analyst, preferably one who also has technical knowledge, and a developer, going out to talk to the customer together. They can both see how the customer works and what they do and after that the analyst can work it out, but the developers isn't blank either. It's also good for the users and developers to get to know each other because it becomes easier for either of them to send and email or just pick up the phone. Of course there are also many companies who shudder in fear of the idea that a developer and a user are in direct contact with each other.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
The spec I just received sounds like it came from your guy. In a nutshell, it was: - Remove hard coded Customer Type from routines A and B. - Hard code Customer Type in routine C. There was literally, no explanation as to why/what the problem was - and not one example. The coding took about 15 minutes. I then asked him for pointers on how to test - and this is what I got back: "The Customer Type is incorrectly set to 'X' which results in the wrong value in the transaction". :confused:
Sander Rossel wrote:
Of course there are also many companies who shudder in fear of the idea that a developer and a user are in direct contact with each other.
and sometimes they're right! :-D
-
The spec I just received sounds like it came from your guy. In a nutshell, it was: - Remove hard coded Customer Type from routines A and B. - Hard code Customer Type in routine C. There was literally, no explanation as to why/what the problem was - and not one example. The coding took about 15 minutes. I then asked him for pointers on how to test - and this is what I got back: "The Customer Type is incorrectly set to 'X' which results in the wrong value in the transaction". :confused:
Sander Rossel wrote:
Of course there are also many companies who shudder in fear of the idea that a developer and a user are in direct contact with each other.
and sometimes they're right! :-D
-
I know a guy who's completely into the technology, but has no eye for businesses. He'd send out emails to customers saying stuff like "When you click the button we do an AJAX call and in the POST we store the entity in the database through a foreign key relation." Well, maybe not that bad, but you get the idea. Luckily, I checked his emails before he'd send them and it simply didn't occur to him to simply say "when you click the button we store the product." That was way to simplistic according to him. I once had a customer who didn't want to speak to a coworker anymore exactly because that coworker talked like that and the customer didn't understand him and wasted his time. Because I've worked with many developers who are like that I'm for the duo. An analyst, preferably one who also has technical knowledge, and a developer, going out to talk to the customer together. They can both see how the customer works and what they do and after that the analyst can work it out, but the developers isn't blank either. It's also good for the users and developers to get to know each other because it becomes easier for either of them to send and email or just pick up the phone. Of course there are also many companies who shudder in fear of the idea that a developer and a user are in direct contact with each other.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I know a guy who's completely into the technology, but has no eye for businesses. He'd send out emails to customers saying stuff like "When you click the button we do an AJAX call and in the POST we store the entity in the database through a foreign key relation." Well, maybe not that bad, but you get the idea. Luckily, I checked his emails before he'd send them and it simply didn't occur to him to simply say "when you click the button we store the product." That was way to simplistic according to him. I once had a customer who didn't want to speak to a coworker anymore exactly because that coworker talked like that and the customer didn't understand him and wasted his time. Because I've worked with many developers who are like that I'm for the duo. An analyst, preferably one who also has technical knowledge, and a developer, going out to talk to the customer together. They can both see how the customer works and what they do and after that the analyst can work it out, but the developers isn't blank either. It's also good for the users and developers to get to know each other because it becomes easier for either of them to send and email or just pick up the phone. Of course there are also many companies who shudder in fear of the idea that a developer and a user are in direct contact with each other.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
A small part of my job is to provide support for customers. I avoid get into implementation details, but I don't shy away from trying to explain, at a high level, why things work do they (or don't) either. I never try to sound condescending however. I think most customers appreciate the fact that I don't treat them like idiots. At the same time, I don't "go deep" as I would with my developer coworkers. It's a fine line.
-
A small part of my job is to provide support for customers. I avoid get into implementation details, but I don't shy away from trying to explain, at a high level, why things work do they (or don't) either. I never try to sound condescending however. I think most customers appreciate the fact that I don't treat them like idiots. At the same time, I don't "go deep" as I would with my developer coworkers. It's a fine line.
Same! I even have a customer who asks me about it and says he appreciates that I take the time to explain it to him in simple terms :D
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
The spec I just received sounds like it came from your guy. In a nutshell, it was: - Remove hard coded Customer Type from routines A and B. - Hard code Customer Type in routine C. There was literally, no explanation as to why/what the problem was - and not one example. The coding took about 15 minutes. I then asked him for pointers on how to test - and this is what I got back: "The Customer Type is incorrectly set to 'X' which results in the wrong value in the transaction". :confused:
Sander Rossel wrote:
Of course there are also many companies who shudder in fear of the idea that a developer and a user are in direct contact with each other.
and sometimes they're right! :-D
Yeah, been there done that :laugh: Sometimes I just ask "what are you trying to achieve?" And if they'll say "that customer type is not hard coded." I'll follow up with "and how does that affect the outcome?" or something like that.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I've worked with people like that; they get completely engrossed in the detail to the point that they can't see (or explain) the bigger picture.
Oh yeah, but this works two ways! As a developer I've sometimes been kept from the bigger picture. For some reason, people sometimes see us as idiots who wouldn't get it anyway. Probably because we're to up in our technology. Now that I'm a manager myself I always try to get a tour of the factory (if applicable) for me and the programmer(s). If it's not a factory I at least try to explain the overall process, like "we get document A in an email and after that they open our software and do X and Y so at the end a price is emailed back to the customer".
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Years ago I worked on a sub-part of a business application, that was written in Assembler. When the spec came over from the Analyst(s), it even told us which registers to use at each step.
I worked with someone like that Richard, his specs were so good/detailed/accurate he might aas well of coded it (and he could of).
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
-
I've been in software development a long, long time. And I've always believed that the Analyst Programmer role was the best option, when it comes to getting things done. I should qualify that: - an Analyst Programmer needs to have a good understanding of both the business and the technology/systems - by "best", I mean most efficient. This was borne out a couple of jobs back, when the software development team I was working in, consisted of experienced developers - and Analysts who had less understanding of the business, (than the developers), and no understanding of the technology/systems. Invariably, on receipt of a spec, developers would need to: identify actual requirements by talking to users; correct half-baked ideas that weren't in line with the technolgy; and devise their own testing. Analysts were actually making the whole job more difficult. Most - if not all - of the senior developers would have provided a quicker/better solution if they had done the analysis and spec work themselves. Yeah. Analyst Programmers. Don't get me wrong. There are developers who shouldn't be let near a spec... or a user... and, in some cases, a keyboard. But they are the exception. But there is one "blind spot" that a developer needs to overcome before taking on any sort of analysis role. Fast forward to today. I'm currently doing a few small jobs for a big company that has a small development team... and a "Solutions Architect". The Solutions Architect has been with the company for many years; started there as a programmer; has an in-depth understanding of both the business and the technology; and produces all the specs. But... His mind-set is 100% that of a developer He has that "blind spot". And it's right there in his job title. What I want from a spec is a clear explanation of the problem - ideally with examples, that can provide the basis for testing. Want I don't want from a spec is just a solution. It's an easy trap to fall into. Developers tend to be fixers/solvers of problems - i.e. solution providers. If you can't explain the problem - the "why we need to do this" - you shouldn't be producing specs. Remember... this just MHO. :)
I've been a solo developer in a small company for almost 25 years and I've hardly ever worked from 'specs'. An exception was the last web application that just rolled out a few months ago where the customer provided spreadsheets (order sheets) and said 'Make it look like this.' They also provided sample invoices and reports. The project took around 9 months to 'complete' and so far (knock on wood) has been the best product rollout that I've ever been a part of. I attribute that mostly to the customer knowing exactly what they wanted and working from sample output/reports. We also had weekly teams meetings during development which I hated, but were essential. Typically, our customers/end users have very little input into our product's designs. For the most part, our products are very niche and everyone on the team has > 20 years experience working either directly or indirectly in that niche. Customers rely entirely on us to make something that works. If they come up with a good idea, we steal it then charge them for it! :laugh: For the most part, there are no specs...we just make it up as we go.
"Go forth into the source" - Neal Morse "Hope is contagious"
-
I've been in software development a long, long time. And I've always believed that the Analyst Programmer role was the best option, when it comes to getting things done. I should qualify that: - an Analyst Programmer needs to have a good understanding of both the business and the technology/systems - by "best", I mean most efficient. This was borne out a couple of jobs back, when the software development team I was working in, consisted of experienced developers - and Analysts who had less understanding of the business, (than the developers), and no understanding of the technology/systems. Invariably, on receipt of a spec, developers would need to: identify actual requirements by talking to users; correct half-baked ideas that weren't in line with the technolgy; and devise their own testing. Analysts were actually making the whole job more difficult. Most - if not all - of the senior developers would have provided a quicker/better solution if they had done the analysis and spec work themselves. Yeah. Analyst Programmers. Don't get me wrong. There are developers who shouldn't be let near a spec... or a user... and, in some cases, a keyboard. But they are the exception. But there is one "blind spot" that a developer needs to overcome before taking on any sort of analysis role. Fast forward to today. I'm currently doing a few small jobs for a big company that has a small development team... and a "Solutions Architect". The Solutions Architect has been with the company for many years; started there as a programmer; has an in-depth understanding of both the business and the technology; and produces all the specs. But... His mind-set is 100% that of a developer He has that "blind spot". And it's right there in his job title. What I want from a spec is a clear explanation of the problem - ideally with examples, that can provide the basis for testing. Want I don't want from a spec is just a solution. It's an easy trap to fall into. Developers tend to be fixers/solvers of problems - i.e. solution providers. If you can't explain the problem - the "why we need to do this" - you shouldn't be producing specs. Remember... this just MHO. :)
5teveH wrote:
His mind-set is 100% that of a developer He has that "blind spot".
What you are describing is a business problem. Titles have nothing to do with it. The basic hierarchy is - Customer - Requirement/business cases - Architecture - Design - Implementation - Test - Delivery - Repeat steps as necessary. And there are other factors that influence that. - Providing a solution that is robust, fast, etc. - Updating old code - Security - Making sure that something is delivered so money can be made to pay the bills. - etc The roles that any one person might successfully fulfill depend on their own experience and their coworkers skill as well. An 'architect' might be able to fulfill the first 4 roles but not be great at the detail work needed for the levels under that. A developer might seem to have adequate knowledge of both the business and the code but fail when the business changes. Of course failures can come from many places. I know of specific case where a service was created, delivered and successfully used but a contract very early in the company history guaranteed they could not make enough money to keep going. In another case a design or perhaps implementation decision lead to a multi-billion dollar company failing in less than a year due to a security problem. Or a developer that was handed a detailed design and decided to ignore it producing a solution that did not meet the business needs the design dealt with. This is all impacted by complexity. A single man shop would need to provide all of that. But when a company has thousands of employees single employees just cannot learn everything needed to manage all roles. I have worked at companies where test automation was handled by a team of employees.
