hypothetical hands-on senior-level course on production code development.. by John Jan Popović

Essay on production code development
Albert Einstein once said: "Reality is merely an illusion, albeit a very persistent one." - Well, I'll give a perspective from the market view-stand: end users gives a damn whether your code is 'good', or "good enough" -- as long as the Black-box works fine.


-------------------------------------------------------------------------------------
hypothetical hands-on senior-level course on production code development
--------------------------------------------------------------------------------------
In academia there is no such senior-level course on coding, which would prepare programmers for real life assignments.
In that production code development course, the class is subdivided into smaller teams, and then given them vague and incomplete requirements with some marketing objective like:
>> We need some "simple" billing software client-server, uh, with web and user interface program that lets the user, uh... make fiscal bills is his small shop. In two months we must have something operational in production. Within three months, we must have a code in production.<<

After two weeks to me it was clear that client-server system can not work. Fiscal certificates can not be stored on on thin-client terminals. The cloud solution is feasible, and Fiscal certificates will be stored in Cloud. It will be multi-tenant solution. DBase solution would be too slow and not scalable, and flat-files were more convenient approach.

Any request for more detailed specifications would be ignored. Ad hoc solutions will be done by developers on fly according to their "good-enough but incomplete understanding of the business case"

We will have good HelpDesk which will "cover and report" all bugs and smooth-out customer's frustrations for disservice and end-users problems.

Project manager will review the prototype, report the most critical bugs and tell system developers what is wrong, and send them back to the drawing board, to tweak or fix the problem.

After some more weeks, marketing experts will request requirements changed, and insisting to add -- billing reporting with book keeping features --

Two months later I'd tell the senior-programmers who attend that hypothetical hands-on senior-level course on production code development training that we need to have particular plug-in with some additional features because of EU legal compliance for the fiscal billing regulative.

And then again a few weeks later I'd tell that the date are not safe and that there are some security issues which must be fixed as soon as possible. And after that will arrive sudden complain on HelpDesk that the system is secure but it is toooooo slow now. We must do roll-back and do something to fix "fast security".
And then we'd have last review, and I'd tell students/senior-programmers in that hypothetical hands-on training course that the "feel" of the program is all wrong, and all needs to be redone.
At the end I as mentor would just tell students/senior-programmers in that hypothetical hands-on training course that're being failed. And that they are incompetent and that the project is the failure. And I will tell them that I am disappointed with their clumsy and sloppy software solution. It sucks and they have failed.

I think that such tough production code development training is of vital importance to prepare software developers for real life combat (i.e. production) situations.

Oh, yes, that project was awarded with the GOLD medal, and all merit is on business-marketing side and the all blame is on software engineers.

Such senior-level course would prepare software engineers for real life assignments, and make them tough in their interactions with upper management and business-marketing stakeholders.

--------------------------------------------


Single development criterion is: Code has to pass user acceptance test, with no obvious bugs and in production must be on time or before deadline even better. If it is written in Aramaic or Klingonic -- It does NOT matter!


End users will not address the problem of no one being able to read the damn thing down the line as long as the Black-box works fine. You can rewrite the "black-box" later, when there are more than 10000 users in production, and guaranteed cash-flow.

----------------------------------
Marketing / Business objectives
-----------------------------------
- make it work
- make it right
- make it fast

One thing that's always missed is the distinction between correctness and robustness.
Correctness: It does the right thing when fed the right inputs.
Robustness: It doesn't do the wrong thing when fed the wrong inputs.
Correctness takes 10% of the time and provides 90% of the value, while robustness takes 90% of the time and provides 10% of the value.

If management hits their goals by getting the feature delivered on time, but the bugs are your fault, obviously they just want you to get it done NOW (in capital case), not considering the complexity or quality. What I would suggest is that you thoroughly document all your objections, with warnings of quality issues with insufficient time, and hope this covers and protects you when there are the bugs or when the system or even the whole project fails. Then to change your client, or find a new job is often the best option.

On the other hand, if you don't get your code done and ship the product in a timely manner, NO ONE will ever read your code because your client or your company will lose the market, and a competing product will win the battle for customers. Some legacy B2B software vendors are getting destroyed by new SaaS Cloud solutions in perpetual beta.

When a bug is reported... documented... reproduced.. it is possible to fix it.

Then you can think how to make it:
- reliable
- secure
- maintainable
- reusable
- controllable

-------------------------------------
Refactoring and Rewriting the code
-------------------------------------
Often in a money-making production software, a change that should take 15 minutes ends up taking 15 hours because the code is too complex. Rewriting the system to make it easier to maintain would likely take time for testing, coding and refactoring.
Refactor the code. Reverse engineer it. Rewrite it bottom-up. Do what ever fits you the best.
But think, do you know upfront the answers on these questions before you start refactoring:

1. Can you do it on time?
2. Can you do it on budget?
3. Can you deliver the better performance/quality and not introduce new bugs or compromise the present functionality?
4. Will this initiative reduce the complexity, and improve the readability of the code?

Finding the proper balance between the speed of development and shipping the product on the market and quality of software "get it right from the first time" is going to depend on the individual circumstance, but your first priority should be covering your OWN interests.


Of course do managers, QA, users, find it 'good enough', well, good enough, that is the question. Is there good refactoring plan?