Monday, October 23, 2006

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.


Blogger Vikas said...

Excellent Post. Vacation really worked out nicely for you. :)

Hi Survic,
Excellent Post. Vacation really worked out nicely for you. :)

Business Analyst-
I agree with you with all the points. It is very easy to give up technical skills rather than acquiring them.
I am sure that you are not suggesting that there is no need of pure business analyst people in the project since developers have the capability to perform that role. One speaker in a .Net event raised a nice point about the need of a business analyst. His contention was that users don’t know their requirements properly and developers are looking for challenges. So developers can take half thought requirement and convert it into a system and finally leading to disaster. I thought that Speaker had really good point.

Exellent point. Young kids have excellent energy, keenness to learn, hunger to prove themselves while experienced programmer have domain knowledge and cautious approach towards technology. This leads me to thinking about one more detailed post how experienced programmers can easily learn new technologies.

Agree with you. This gives food for my next post “Why strong Developers does not mean necessarily good Architects”

Excellent point. People are going to judge a car by its body, it structure, its pleasant and cool looks. There is no excuse for this. Lot of software developers (including me) has imposed a barrier on their mind that it needs a good artist to create cool GUI. As someone said, “Good Artists create Excellent Artists copy”. Keep this mantra in mind.

Every Army General claims to be a soldier first but not Project Leads, Architects.

I think that here, Survic is only focusing on certain kind of projects but not on wide spectrum of industry. I agree with him in that context.

10/28/2006 06:03:00 AM  
Blogger survic said...

I definitely feel the need of business analysts. My key point is that developers – as long as they still want to be developers – should not overdo the business analysts’ role. I should have point it out more clearly: they should request the existence of business analysts – thank you, vikas, as always, you make my argument complete :-)

How an old dog learns new tricks quickly – I am waiting for your post. For the time being, it reminds me an approach: abstract a little -- not too high level, but a little bit higher than programming-“design pattern” – in my case, it is the “8 core techniques”. By doing this, I managed to switch languages and platforms and their versions. -- This seems to be widely used technique. For example, Rocky has been using the CSLA framework as the higher level vessel.

As for tester, you said, “Survic is only focusing on certain kind of projects but not on wide spectrum of industry”. You are right of course. However, I also want to address the whole industry! -- I am trying to understand the almost unbelievable phenomenon: only software industry “enjoy” such a low quality warranty and yet such a big profit! I understand the importance of quality, but I also want to see the reality and want an explanation of the reality.

10/30/2006 12:43:00 AM  
Blogger Vikas said...

"abstract a little -- not too high level, but a lttle bit higher than programming --"design pattern."

Wooooooooooooooooow. That was my thinking too. That is what that differentiates an architect developer from a very strong developer. Some years back, you were an architect because you survived working for five years and you were developing as Microsoft/Sun told you. I could not understand for some time that why some strong developers (I know lot of exceptions though) lack an Application Architect's prospective. This is the same conclusion that I arrived at.

Only software industry “enjoy” such a low quality warranty and yet such a big profit

Well said. Software that delivers business value and High Quality Software are not same. Why waste money to take Software from point A to B when businesses are not in business of software business. Sarcasm intended.

10/30/2006 08:36:00 PM  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home