the balance of hats for a developer

the balance of hats for a developer

Another perspective about “process”: in the beginning, there are only developers, then, you add more specialized persons to the team …

Note that when I describe the downsides, I am mostly describing myself – only by making the mistakes myself, I know how tricky it can be! For example, when I was happy about my domain knowledge, I forgot I was giving up technologies -- you see, you can only do one thing at a time (well, I mean do one thing really well), so, you got to give up something. By itself it is OK; however, you also need to be aware that you have given up something else.

---- Analyst (“business”): a good developer should be able to do it, there is absolutely no excuse to wait for a “spec”. A good developer must be able to talk to users and understand their needs – which means he/she knows the domain well or can learn very fast, or both. However, if a developer begins to believe her/his main skill is the domain knowledge, then, it is a red flag. It is a red flag, because for the company it almost always means there is a single point of failure. For the developer, it almost always means he/she gradually loses his/her ability to learn new technologies. Also, analyst-developers tend to fail to identify “common features” that can be centralized in architecture design.

You may ask: is there any reason that a developer needs to do the analyst’s job? There is no process that can be that perfect -- a developer has to talk to users to understand the business processes -- it is not whether, but when and how much. In addition to that, there is another more explicit reason. Nowadays, there is almost no business process that is not using computers at all. As a result, the person who is doing the requirement gathering needs to understand the programs the business processes are currently using. You may say, we can ignore that, we can just talk to users, and do everything from scratch. It is certainly possible; further, I would admit that it does have the advertised advantage that our “brand new” perspective is not limited to the current software packages. However, it is very costly, slow, and risky – I know a lot of business persons do not believe what I have just said; also, I know that a lot of pro-process people do not believe what I have just said; however, what I have just said is absolutely the truth – it is the core cause of most failed projects: trying to gather requirements purely from “users” is so ineffective that it is almost WRONG to do it that way. A better way is to use two-leg approach: you interview various levels of users, and you study the current programs.

To study the current programs, you need developers -- you can train some developers to understand business; but you can train few business analysts to understand software programs -- even those business analysts were developers a few years ago.

However, my point here is that unless you are making an explicit decision, do not overdo it! As a developer, business analysis is only a part of your core skill set. Unless you are a genius, once you have overdone it, it is a no-return trip: once you are a "pure" business analysts, it is very difficult to be a developer again. Consider being warned.

Another thing is that it explains why experienced “old” developers are valuable. Any kids just from college can do .Net 2.0 programming once it is “spec-ed”; only experienced developers who know VB6, VB3, perl5, and C, can deal with a real project from the very beginning to the end.

However, again, my point here is that experienced “old” developers need to work very hard to keep learning new technologies fast. The key word is “fast”. They should learn faster than those brand new “kids” – this seems easy, but unfortunately and sadly, it is difficult, because computing technology change so fast. I have seen too many struggles between “old” guys who cannot learn new tricks, and “new” guys who has no clue but know how to play a few new toys. My bet is on the “old” guys, because “no clue” can only be changed by experience and time. However, “old” guys must learn, and learn fast. Otherwise, those struggles lead us nowhere.

---- Architect (“technology”): a good developer should be able to do it; however, if a developer begins to believe he/she is too good to do hand-on programming, or, the team believe an architect is more “worthy” than a senior developer, then, it is a red flag. The problem is that new technologies emerge and change so fast, they do not “conform” to the “layers” or “hierarchies” -- a lot of times, a little thing can tip off the whole architecture decision. As a result, solid architecture design decisions must be based on a few “prototypes” (or “template programs” or “example programs” – or whatever names you prefer). Also, when architecture is the whole focus, the team will pay too much attention to fancy stuff, resulting over-design and over-engineering, missing the deadline, and create a big mess of fancy useless stuff without business values.

---- GUI designer (“art”): a good developer should be able to design a usable GUI -- there is no excuses to say that “I am not good at UI”. Further, if necessary, he/she can create a context that a GUI-graphics expert can continue to work on. The key is that the developer must know a lot of GUI and graphics so that he/she can drive it, not the graphic expert. I know this obviously has a developer’s bias; however, this is critical, and, I am emphasizing that the developer must learn GUI and graphics (likely from graphics experts!) in order to drive. On the other hand, ordinary GUI design is nothing to be bragged about; it is, well, “ordinary”. If a developer begins believe he/she is an expert on GUI, it is red flag. It usually means -- sounds paradoxical, he/she is bored with GUI. Computer Graphics/GUI change so fast, nobody can be an “expert” on it. Learn fast, and keep it simply within common senses, are the best we can do.

---- Programmer (“science”): This is the core. However, too many times we have wasted our time on trying to choose the “best” algorithm when it is totally irrelevant -- it is very important to know when science is relevant -- using common senses.

---- Lead (“politics”): Either lead or follow; nothing in between. However, you must be able to do both -- sometimes even simultaneously: delegate and then follow.

---- Tester (“a fancy name?”): XP makes it clear that a developer needs to do testing – good unit testing can eliminate more than 90% traditional QA testing! Being able to write, easily and quickly, 3-in-1 “func spec/test script/user manual” is crucial. However, having said that, I want to balance it with the following: no need to be addictive! For most software, deadline and features (in that order) are certainly more important than testing, or, even quality – this not to say quality is not important, it is just the reality that most “business process” has inherent redundant fault-tolerant mechanisms, as a result, quality is not as critical as it is for bridge or airplane building.

---- DBA (“a fancy name?”): developers should understand almost all database features (except backup and details of volume management, and some details of performance tuning). When there are “development DBAs”, those DBAs can drive the database table design; otherwise, when there are many new tables, developers must be capable of driving the table design – regardless whatever company or process you are in, because “use cases” determine everything, and DBAs do not know “use cases”, so, developers must drive. If the “process” does not allow this happen directly, then, it will be done indirectly in a zigzag style – we can even say this, technically it is not THAT difficult, so, usually it is a few days after developers are allowed to participate designing tables, directly or indirectly, then, it will be done (for a certain iteration, of course). Note that if there are mostly changes of existing tables, then, DBAs drive the process.

---- System Admin (“a fancy name?”): Developers need to know how to install, deploy, and secure software. Usually they are the driver of the first deployment, with the help of persons from system admin team.

---- Support (“a fancy name?”): Developers need know how users are using the software as their everyday routine. So, it is always good to ask developers to do support for two or three weeks in a year or half a year. Note that I do not mean the “level-three” support; I mean the “mundane” everyday support. Note that usually “support” has a lower status in many people’s mind. So, managers usually do not want to “offend” developers to ask them to do support (unless it is in crisis or the “level-3 support”). So, developers should take initiative. Another way is to combine it with requirement gathering, that is, to support a to-be-replaced software as part of the requirement gathering process. If you work in a strict process-controlled environment, this is especially important – you need to find every opportunity to talk to users in person: requirement gathering, QA, deployment. If you do not do that, man, you are just a programmer, not a developer.

A good developer must maintain a healthy balance among those hats, and work with persons who wear those hats as their professions and “delegate” accordingly, with the understanding that “in the beginning”, a developer is supposedly to do all the jobs, and in most cases and places, a developer will still need to wear multiple hats if not all those hats, and it is actually “normal” and even “healthy” to do that.