This post on Program manager by Joel Spolsky describes what a program manager does, how to become a better one and what the role distinctions are. The main idea is that a program manager provides the specifications, communicates the design and serves as customer advocate.
This definition is quite similar to the task of a system engineer: (from INCOSE)
Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem.
What is comparable?
Defining customer needs - same as being customer advocate.
Required functionality - specifications.
Documenting the requirements - communicate.
To me is seems that the roles are very similar especially considering the following list:
the tasks are similar
the competence required for the job is similar
the role is a peer to the developer
the role should generate a positive conflict with the developer
the role should gain respect from the programmer
So why do we have two definitions?
System engineering profession came into existence for systems that required large cooperative effort in Bell Labs.
Program manager was described in the mythical man month as the "chief programmer" with enough experience to detail the functional and performance specifications.
In my opinion these two definitions of roles come to life because of people working in different worlds using different vocabulary and still facing the same problems of complexity and distribution of work. System engineering handles complex multi disciplinary projects and designs, where program manager handles the same, but in a software only world.
Since most system are becoming more software intensive, replacing tasks done previously in hardware with software solutions, the system engineer becomes more involved in software design, in a way performing the same tasks as a program manager for software projects. The evolution of the system engineer only confirms that the distinction is only artificial only due to the nature of separation of worlds.
Back to the original post, Joel's suggestions are valid for system engineers, especially the part of earning peers respect's while keeping your head open and learning.
Last week I got a call from a past coworker, asking for design guidelines and comparison between storage vendors. The question itself does not surprise me, but he wanted the information distilled into a few sentences, so it can be presented to management for decision taking.
The situation raised a question; can design be done quick and dirty?
The Agile process promises shortening development time by leaving the waterfall method of design up front, and instead do it on the move while coding. YAGNI promises limiting the design only to parts really used and KISS provides a sound reason for doing it simple. To put it in a few words, the processes above try to replace the waterfall model with something interactive, where design changes with the experience learned while coding and allowing for maneuver room as requirements change.
What do I perceive as a problem in the agile processes?
Design in parts can corrupt the conceptual integrity and provide very limited concepts at the start
Technical debt due to development done according to limited design
Limited infrastructure design can lead to architectural changes along the way
Should one or more of these problems occur, the presumed gain in time will be lost due to architectural modification and probably code rewrite.
Are there other options? Or just Agile vs. Waterfall?
I believe that the extremes are too extremes, that some compromise should be taken. And this is where I concur with Joel, on having requirements and initial design up front. Agile processes can be then used for low level design and coding when the gross conceptual framework is already defined.
Would I be in my coworker place I would take time to design the main components of the system, while analyzing the requirements deeply. These are the major components that need attention and not use snippets of information for decision taking.
Since software is a solution to some requirement, software evolves, the same way as requirements evolve. This is true for games, commercial applications and open source projects. This evolution comes with a cost, as so well described by Jeff Atwood. For me, the process is very familiar because it occurs in almost any project with a large lifespan.
While the post itself is interesting, some of the comments were enlightening, mainly on how people fail to see the problem. Specially this comment:
This post pretty much boils down to "we have to refactor/rewrite some stuff on our software project" - Big deal, so do I; and probably so does the poster above me, and the one above him.
Details Jeff, is what makes a technical article... technical. Otherwise this could have been written by a 2nd year business major.
The problem is not that you have to refactor/ rewrite. The point of the article is that refactoring/rewriting is part of the process, of understanding the why .
The reason code rots or accumulates software debt varies, but has some very simple reasons:
The requirements change
The design is rushed / non existent
The development is rushed
The testing is rushed / non existent
Code fashion changes
Any of them or a mixture will cause software debt, and almost all of the reasons will apply in a larger project. Thus you need to take into account a refactoring phase that can sometimes be large as an architectural change. Because most of the refactoring occurs after the original code has been long used we as programmers see it as "WTF" who wrote this, forgetting that it might had some real reason long ago.
Laugh all you want of previous mistakes, you will make your own mistakes mainly because requirements change.
Users can tell you more with actions than with words, this fact is long discussed by Jakob Nielsen as a problematic communication issue. Instead relay on actual information and gathered statistics.
Taking this into actions I looked at the detailed statistics of the site and saw that most people read the page linked from outside and immediately go to the link "Contact Me". I wasn't aware that having a biography was so important.
So the news are that I've added a biography section, to be updated every once in a while.
