Early in my career I had a brief stint as an engineer at a consulting company in the ERP industry. Our projects always had at least one functional consultant whose expertise was _using_ the ERP systems and understanding how they integrated with other systems and procedures. This was a different position than PM, who was often an employee of the client company who drew the short straw.
The functional consultants had varying degrees of technical experience (some were highly technical, including having CS degrees), but in general they were people who in a previous life became really good at managing and hacking their company's ERP system, became the goto person to deal with crap, and figured out they their domain knowledge was highly valuable.
The competence of our technical consultants was questionable. On my first project the senior tech consultant told me that I was the first person he worked with (himself included) who structured his code into modules. He was like, "it makes it so easy to use your stuff!" :) But the functional expertise was excellent and the reason the company had an excellent project success rate.
The company basically imploded after some senior technical engineers and managers bought into the Java and XML fad. Their plans failed horribly because the technology was too complex for the technical consultants (not to mention too immature), and it left little room for leveraging the expertise of the functional consultants as pivoting to Java and XML effectively required reinventing everything. Chaos ensued and, after being bought by a major ERP systems vendor (ironically for their strong project success rate), effectively disbanded.
A functional consultant on our team who is great. Connected to their functional consultant who was wildly differing in skill level, from expert to can barely use a computer.
Technical Consultants, which involved 1 Senior who knew everything about one segment of topics. Another Senior who knew everything about a different segment of topics. A junior to learn things. And the PM which was also the sales lead looking for more work.
1 of those Seniors needed to be able to have social skills and diplomacy, the other didn't. You could hide the 2nd through preplanning.
The junior just needed to know to keep his mouth shut.
Then you'd have a variety of other seniors who you could call in on a particular topic, but you'd try not to use, as they are on projects.
And in our case, we had a GM who was more functional than all of us, almost as technical as all of us, and the best in front of customers. He could be brought in to deal with any special scenarios, and to gut check our plans.
So we were really, ridiculously successful with that model.
Basically, really well paid, SMEs, no cruft except a younger guy to learn on the job. Such a good structure.
Amusing to me that people consider a ton of modules to be a sign of high code quality.
What was your role in the project? Did you swoop in and do a copy and paste refactor into a bunch of tiny files and declare your victory?
I’m going out on a limb here but I’m going to say you’re a little bitter at the value of the consultant vs. your own textbook, indignant idea of value.
You obviously never used Allaire ColdFusion, before it got fancy features like functions.
IIRC, a "tag" was the closest equivalent to a function, but it was basically a parameterized textual include. A "module" was a "tag" that didn't need to be installed into a special directory. During development the only easy way to not have the source code for your entire application in a single logical source file (split across unparameterized includes) was to use modules. Using tags was a PITA because of the need to install them in a special location, but for [reasons] people never bothered using modules at the time.
So to better understand the context, s/modules/functions/.
The fact that I uniquely used modules says less about my competency (or the competency of any particular consultant) and more about the general technical competency of the organization. As I said, some of the technical consultants had CS degrees so they fully understood the concept of functions, as well as more difficult concepts. The senior consultant I mentioned had a CS degree. I didn't mean to imply that I thought I was more competent than he was; quite the opposite. I remember what he said to me precisely because he did have a CS degree (which I lacked), was one of the most experienced consultants at the company who had worked with most every other technical consultant, and was someone I generally looked up to.
And you conveniently skipped my larger point which was that the organization was successful without strong technical competency. All things being equal you want strong technical competency, but especially in the world of ERP systems where everything is highly customized and a tremendous amount of code is ad hoc business logic, functional competency is incomparably more important for achieving project success.
The functional consultants had varying degrees of technical experience (some were highly technical, including having CS degrees), but in general they were people who in a previous life became really good at managing and hacking their company's ERP system, became the goto person to deal with crap, and figured out they their domain knowledge was highly valuable.
The competence of our technical consultants was questionable. On my first project the senior tech consultant told me that I was the first person he worked with (himself included) who structured his code into modules. He was like, "it makes it so easy to use your stuff!" :) But the functional expertise was excellent and the reason the company had an excellent project success rate.
The company basically imploded after some senior technical engineers and managers bought into the Java and XML fad. Their plans failed horribly because the technology was too complex for the technical consultants (not to mention too immature), and it left little room for leveraging the expertise of the functional consultants as pivoting to Java and XML effectively required reinventing everything. Chaos ensued and, after being bought by a major ERP systems vendor (ironically for their strong project success rate), effectively disbanded.