IBM Security Guardium

 View Only

Make your job easy, so you will have more time for family/Netflix/Disney+

By Kenneth Cheung posted Tue May 19, 2020 11:38 PM

  
bill_gate_quote.png


Bill Gates has been quoted as saying, "I choose a lazy person to do a hard job, because a lazy person will find an easy way to do it." It may not really have been him who said this, but people give him the credit anyways — and in any case, it's a good quote.

Software development can be hard, especially when time is tight.  Don't you want to make it easier so you will have more time for family/Netflix/Disney+?

Having worked on many different projects, some went smoother than the others, I have seen practices that would make people's life easier.

Frontload the productivity enhancement activity


Abraham Lincoln was quoted as saying “Give me six hours to chop down a tree and I will spend the first four sharpening the ax.”

Make the debugger/test environment available before you even begin.  The early you do it the longer you (and your teammates) can enjoy the gained productivity.

Figure out how to perform cross-component testing locally without waiting for code to be checked in and built by external process.  You want to save all the time you open pull request, wait for reviews and builds only to find out that it does not work, and you have to start over.

Develop backwards

One trick we learnt as  kids when doing maze puzzle is that it is much easier to draw a line from exit backwards back to the entrance.  The chance of hitting a dead-end and backtrack is much lower.

maze.png 


A team leader needs to define the “moment of truth” for the scenario to be implemented right off the bat.  It refers to the behavior that you want the user to see at the end of the scenario.  There is no point coding if you cannot show that part works. The team then work on the scenarios backwards from the output.  The most initial implementation may just be returning a hardcoded output.

The advantage is that there is less chance to find out something is missing at the end and having to fix all previous steps.

Another advantage is that there is always something to show the stakeholders.  The output is only mocked at the very beginning of the cycle.  On the other hand, if you start from the beginning you run the risk of having nothing to show until the very end.

Create an Instant feedback loop


Don’t you wish there were a VSCode (or any weapon of your choice) plugin that tells you when you have created a bug?  It does not exist yet, but by ordering your development tasks correctly you can almost achieve that.

From experience to fix a defect, usually 80% of the time is spent on finding where the bug is, 20% of the time is spent on fixing the bug.  To improve the velocity of development the easiest way is to reduce the time to find where the bugs are.  For that you will not even need to improve your coding skill but you will need discipline.

The idea is to create an instant feedback loop that if you do something wrong, a green light will turn into red.  The reason is that it is not very often that you will not make any mistake along the way.  The longer you write code without the instant feedback loop the longer it will take to debug (often exponentially).

Hopefully you already have a testcase that tests end to end.  (If not you should create one now.  You want to see you are not causing any regression.  Otherwise if something goes wrong you would not know whether it is your new code or the existing one.  Second guessing waste time and kills speed.)

Resist the temptation to finish writing everything before testing.  Start with something already working.  Make small non-breaking increments.  Run your automated test as often as feasible. If it has to be a breaking change modify the test right away.  Do not wait till everything is completed.  Otherwise you lose the instant feedback loop.

Team leader to use testcase to specify requirement


In a team setting, team leaders can also create testcases that expect the “moment of truth” output and have the team members “make it pass”. It is much easier to do that before the developer starts coding because otherwise:
  • It is hard to reject to approval “just this time” because time is tight:

 dreamworks_cat.png

  • It is also hard to say “proof it” when your fellow developer says “it works.”

Test cases create a clear target for everyone and take “courtesy” out of play.

Now the hardest question you'll have to answer is what you want to watch on Netflix.
0 comments
18 views

Permalink