Dear Software Developers,
This CPTTM Software Developer newsletter is to bring useful news to you, software developers in Macau, for references without obligations, so that you can do your jobs easier and better! Hope you like it. if you'd like to unsubscribe or recommend your friends to subscribe, just let me know. Old issues are available here.
Kent Tong, Editor in ChiefWhen your boss asks you to do more programming work than you can actually do, what do you do? Tell the truth or bite the bullet? As we all want to be good employees, we most likely will bite the bullet and accept it. But how? We only have this much time and energy. Usually, we will either work over time or simply skip testing (in particular, skip writing automated tests). However, this is a really bad practice. Our good intention is hurting the organization.
If we work over time, we will get tired and introduce bugs into the software. I've seen people debugging for hours or even days to find a "simple" bug. So if we work 2 extra hours for a whole week, get tired and introduce a single extra bug which would not have been introduced and that bug takes a day to find and fix, it means the OT (5*2=10 hours) is basically wasted (8 hours used to debug). Are you confident that in that 10 hours of OT you only introduce a single such bug? If you introduce two such bugs, you are hurting the organization.
If we skip testing, the result is even more dangerous. This is like Ford launching a new car without testing it first. According to a research, if it takes 1 hour to fix a bug in coding but we don't do that, then after the product is shipped, it will take 9-15 hours to do that. For an average software project, 50%-75% of the cost is spent on testing. Do we want to scale it by 9-15 times? If the total cost is $100, skip testing will increase the total cost to $500-$1150.
Can we perform manual testing instead of writing automated tests? It may seem faster, but you're making the organization rely on you in the future. Without automated tests, how can other people modify the code without breaking it in the future? If you are a team leader, do you want to rely on a single individual to maintain the software for the rest of its life cycle? What if he leaves the organization or is hit by a bus? In fact, even that particular person may forget about the logic in the code in the future, making the code unmaintainable by anyone.
Therefore, to be good employees, we are responsible for telling our bosses the consequences of committing more work than we can really do. If he chooses to go ahead, fine. It's his decision. But it's our responsibility to advice him of the consequences.
Have any questions, ideas or experiences regarding software development? Contact me at 28781313 or kent at cpttm dot org dot mo.
Until next time,
Kent Tong