In my working environment, over the past few years I have observed an increasing stress on developer management and self-management over technical education.
For example, at work I hear lots of discussions about software development processes, about ways to handle software specifications, e.g. through automatic tests, and so on. I hear less discussions about programming concepts / techniques like data structures, lazy evaluation, memoization, and so on.
To give another example, if I asked a colleague how he would manage the complexity of a certain problem, I would expect that he’d indicate me some solution approach (try to solve a subproblem first, identify subtasks) instead of suggesting a programming abstraction (try using pattern X).
Is it just something specific to my working environment or there is a general trend towards management / work organization and away from the more conceptual aspects of programming?
To make my question specific (and answerable), are there any authors or modern schools of thought that consider organizational aspects more important than educational ones for improving developer productivity?
5
If by “recent years” you mean the last 22 then yes, because that’s all the experience I have to go by. Focus on managerial/process oriented aspects of software projects has been really high ever since I started in the field. If you mean just the last 4 or 5 then absolutely not.
I believe it is effect of two things:
- Many programmers are not part of the “community”. They don’t read blogs, they don’t frequent SO, they don’t watch talks, etc.. That means they have no exposition to the new techniques and paradigms above what they learned in school. And they don’t want to.
- On the other hand, managers at least want to learn new things. They want to learn new processes and methodologies. It is just that they prefer learning the management part instead of technical part.
Case in point: Scrum. Scrum is majorly a management methodology. It doesn’t talk about TDD, pair programming, refactoring, etc.. It is mostly managers who take the “Scrum Master” certifications. Compare that to the Extreme Programming, which was made by developers for developers and contains both management and technical aspects. It can be said that Scrum is just management subset of Extreme Programming.
And in the end, it is still managers who have the last world. Not developers. So when it comes to solving problems, it is management solution that is chosen. And this simply makes developers believe that those kind of solutions are the right ones.
It is part of a general awakening (or maturing) of software engineering.
You can read about this maturing process in No Silver Bullet. Although written several decades ago, its observations still hold true today. At different times in history, various programming paradigms, techniques, methodologies, or management styles were hailed as the “silver bullet” in the sense that it can solve all problems.
A more commercial spin on this “no silver bullet” is known as the Hype Cycle. This is a thesis brought forward by the advisory firm Gartner for explaining the development, maturity and adoption status of some technologies or methodologies, i.e. various things which had been hailed as the silver bullets in the past.
Two examples of where silver bullets don’t work:
(1)
A programming paradigm is widely touted as being able to solve a particular type of software requirements, because theoretically source code that is written with this paradigm had certain properties, and these properties will make meeting the said type of software requirements very easy.
It won’t work if in reality, no software that makes use of this paradigm to solve that type of software requirements exist. What the theory predicts should have existed, may not exist in the real world, unless one or more companies succeeded in making it happen.
(2)
A software architecture is widely touted as having certain desirable characteristics for a certain industry.
A company tries to use this software architecture for this industry, but faces a problem: this company has a large existing code base, and this existing code base doesn’t seem to be compatible or portable to this new software architecture.
A silver bullet that seems to work industry-wide may not be suitable for some particular companies due to individual circumstances.
5
Try to think in layers, like, let’s say TCP/IP: if you’re on the physical layer you need to learn the ‘language’ of the upper layers :))
A programmer shouldn’t NEED to learn Management more than a MANAGER should learn Programming: in other words, as long as you have an idea about what’s over the fence you’re fine…
The next thing is about methods/standards/frameworks, which are GENERAL guidances: they should be adopted and ADAPTED as suitable to any PARTICULAR situation.
Finally, Software Development being a Human activity is prone to FASHION as any other activity: the nowadays trend is AGILE/Scrum/Kanban! [Instead of ‘cascade’ management, simply because it looks cheaper in many cases (not always) …and as any other method it works if applied properly by the right people… Otherwise, please take it from someone who has seen it failing, it can exhaust resources faster than light.]
To resume the above, the answer to your question is another question:
would your (any) CEO (if not of a programming background) learn quicker about programming or about management and fashion?
My personal approach to the above: continuous learning…
1