Its very different when you write scripts for business and for research. Personally, I love to work on research projects since its more lax, and it definitely follows SDLC (Software Development Life Cycle). I've tried working for both kinds, and I say, business related developments are far more stressful.
Here are some of my reasons why they are more stressful than research projects:
- there are no Technical Document whatsoever
- there are no turnover materials
- there is no changelog, and no code repository
- testing is tedious, and it gets skipped most of the time
- deployment is always due yesterday
- there are limited number of testers or none at all
- resources get stumped, rejected or pressed with funding
- feature requests don't get queued or discussed
Its a stressful situation to be in, and so, to remind myself, here are some stress relievers that I can work on, implement or utilize:
- Always setup a separate Development Server, a Testing Server, and Staging Server different from your Live Server. Here, the Development Server can also act as your mail server and/or Codebase Repository
- Prepare Technical Documents as it happens, not when you can prepare them. This can save your life in the future. You can use any facility desired, best to use Wikis and or online services that offer binary files support.
- With this, prepare a Database Dictionary,
- Specs Document
- Technical Manual
- Users Manual
- Deployment Guide
- Change Log / Revisions Compilation
- At the top of Technical Documents, it is worth it to prepare UML Diagrams of the whole system. This way, no matter how quick and fast paced the SDLC is, nothing will ever be broken inadvertently.
- Prepare a team of testers. Include usability, black box, white box, stress tests. Test results document must include bug reproduction, and must be funneled by the Software Development Manager to the correct point person. Testers and Programmers must meet at the point of bug resolution. Proper cycle must be observed for closing/opening of bugs.
Author
