If you work in a normal IT project, this means that someone sent you an email saying "implement me a system which processes credit card transaction", with a couple of documents in attachment explaining the structure of the records.
If you are lucky, you might get a link to some SVN repository where some developer who has already left the company wrote some undocumented code trying to do the same; they will tell you "yes but this code was not good. Now you are an Agile developer and you will figure out what to do".
If you are a normal human being, you will now have a sense of inadequacy and immense responsibility weighing on your shoulders. And a sense of panic, because the work of 4 people (the business analyst, the architect, the developer and the tester) has been entirely pushed to you, without you having the status/authority in the company to go around and demand that some analysis and design is done.
As a developer, you are at the bottom of the company ladder and your only option is to say "yes" (do I sound "victimistic" (=with a persecution complex)?) .Well, no, you have an option to say "no" and you should exercise it, for the good of the project.
My point is: as an experienced developer, your duty is to stand up and say "these requirements are insufficient, we cannot proceed to implementation unless we go through a phase of debate, analysis and design, and we reconstruct the previous attempts that were done on this problem, to learn from the past and gather all the useful information from the people who were involved". It is your duty to say "let me talk to some business analyst, to get the entire picture and document it".
All issues have a history behind. It is important to track this history into a central place. Letting things to stay dispersed is a door open for chaos. They only way to successfully complete your assignment is through full control and tracking. Keeping all the info in a Wiki is indispensable. Better still if you can keep a (b)log of what has been done and needs to be done, with the participants clearly indicated. Keep all participants informed. Blogs and RSS feeds can be useful, although simple emails can do.
Being a good developer is not only about being techie techie... most of the time, it means having a relentless commitment to investigation, communication and documentation. The same skills it takes to be a good historian.
Once I have been asked to perform performance tests on a system. I worked one month setup the environment, to prepare all the Python scripts, measure the metrics, investigate the memory leaks.... by chance, on a Saturday, speaking informally to a colleague sitting 5 meters from me, I discovered that he had done exactly the same thing 3 months before, and already come to a lot of diagnostic. Why management didn't tell me before? Probably they will say "because you didn't ask". This is the world, you cannot change it. Getting mad will lead you nowhere. So, next time, ask "has anybody been working on this before"? There are no stupid questions, you are stupid if you don't ask.
No comments:
Post a Comment