Do not work on unimportant projects

I have heard many times from junior developers that they are working on a project that is not important. This is demotivating a lot when you do some work just to be thrown away after some while. It is just like digging a hole and next day bury it. (Unless, of course, you are a sexton, in which case it makes sense. But that is a different story.)

Once I met a person, who was working on algo-trading algorithms. This is when computers perform tradings and compete with each other executing stock and money trading in milliseconds. He was paid well, the mathematical background was interesting and creating the algorithms was a challenge for him. However he claimed not seeing too much of value of his work to the advantage of the human mankind. He said algo-trading was just machines trading with other machines and nothing else.

We were on a long train travel and had time to discuss, and I explained that algo-trading is a form of competition but not between machines rather between the people who create, execute, maintain the trading. This way algo-trading is an essential part of the evolution that our economy is based on, in my view it may also add to the money liquidity that help the money flow where it really is needed to support investment and innovation.

This person was open to embrace my ideas and was happy seeing that there is more result of his work than just getting the salary. After a half year we met again just by accident (both of us traveled frequently between Budapest and Zürich) and explained that since he believes that his work has real value he is not only happier but also sees the algorithms from a different point of view resulting more success.

Although I believe that the statement above is partly fairy tale, partly result of auto suggestion it still has an important point. You will work better if you know what the meaning of your work is. Being agnostic I know that the life is pointless generally, so the above means that it is only the level how deep you have to dig to find meaning. If you are a shallow person getting paid may make the job important. If you think more complex you want to know what good your work does for the company and through that to the shareholders. If you are a humanistic type you have to know what your work advances humanity, human mankind general. (Be aware not to dig deeper than that risking mental illnesses.)

However what you really have to do: understand the meaning of your work, otherwise it will be no benefit for anybody. Seniors know it.

Happy Christmas!

Advertisement

Outsourcing, Do It Right

Most of the times outsourcing is a nightmare. Companies outsource the activities that are not their core activity nevertheless needed for business to get the job done as cheap as possible. They look at it as some necessary evil, something that would better be not to know all about, forget the details and have it been done. Many times IT is outsourced with this mindset and causes disaster. The problem does not lie in the fact that IT itself is outsourced. It is the mindset. IT can be outsourced and in many cases this is rational to do. The problem is that management many times does not realize that only the T (technology) is what can be outsourced but no I (information).

When you outsource Information Technology running your business outsource only Technology but never Information!

Note that in the expression “information technology” the work “information” is an adjective to “technology” therefore when we speak IT outsourcing we do speak about the outsourcing of the technology and only the handling of the information.

If you are a manufacturer IT is not your core business. If you are an insurance company, or a bank IT is not your core business. If you are doing anything except IT, probably IT is not your core business. You have some system that does the book keeping, resource planning, customer relationship management and so on. This is the technology. Your business can be running fine even if you do not own the knowledge that runs these systems. Does it help you to be a better manufacturer, bank or whatever you are if you own the information technology? Probably no. It does not give you business advantage. If your book keeping is as good as your competitor’s then this is ok as a foundation to compete on other grounds.

The information, however, how you run your business, what makes you a better manufacturer, bank, whatever than others is important to own. That you should not outsource. How you produce , what are the best business processes in your company, how you can adapt to market changes are core business. If you do not care about that and you outsource these core activities to a software technology company they most probably will not provide the best fitting solution for you and the cost may increase, profitability lowers, and your general competitiveness weakens. This task needs business knowledge and companies can outsource this only to companies that have the knowledge and skills. Some software companies do, but in this case these companies are not only software companies but rather consulting-and-software companies. Sometimes you can not tell where the border is. You can hire a consulting company, or you can hire experts as employees. The difference is paper work, sometime taxation. You need the knowledge and you should get it to serve your business goals.

Having all that said, let’s focus on the technology outsourcing assuming we know where business information ends and technology starts.

The major point to outsource IT is to save cost. The outsourcing company can do it cheaper. I have seen many times that on the decline huge companies cut off the IT department, formed a new company, sold and contracted this company for IT outsourcing. The next Monday everybody was sitting at the same desk, doing the same work. How could it be cheaper than some nasty taxation tricks, less benefits from the new company to the employees and similar effects? In some cases such IT companies cut off the body of a huge corporation can survive, but I have never seen any. They inherit the company culture of the corporate that I do not say is wrong, but may just not be the best and most competitive for a small IT company. They stay alive for many years and know one that is alive for more than a decade and is a success story. Whenever you see such success stories remember that

To have a success story you need success and story. One of them is optional.

Really successful IT companies, as I see, come from small and grow big. They learn, as they go how to do IT in a professional way. Focusing the core, working for multiple clients gives the real advantages. The solution at the end of the day can be cheaper using the resources more effectively, having better distribution and better skill matching.

If your problem needs 7.5 person, you can not hire that amount. People are not really effective when chopped into half. You should hire at least 8 persons and find some occupation for the “half” person. An IT company can find that occupation more effectively. They can also easily allocate 15 persons each half time if that may be more effective. If somebody does not fit the task you need not fire the person, the outsource company will find the person that fits best and a task for the person that fits his/her skills. These are possibilities when outsourcing is done right.

If the people of the IT company work only for you and they never submerge into the culture of the mother company then you loose the advantage that comes from knowledge gathered. If the outsourcing company just hires people and sells them out right away they are simply slave traders. That is not the way. If outsourcing is “Let’s get others to do the work that does not mean much to us as cheaply as possible.”, then it is wrong. If it does not mean much to “us”, we should not do it. We should not outsource it. It should rather be eliminated. If it can not be eliminated, then it does mean much.

Just as much as it means for the outsourcing company. Your business depends on it.

Why do we mock?

I do Java interviews. During the interviews I ask technical question that I know the answer for. You may think this is boring. To be honest: sometimes it is. But sometimes it is interesting to learn what misconcepts there are. I happened to ask during the interview what you can read in the title: “Why do we mock?”. The answer was interesting. I can not quote word by word and I also would not like to do that for editorial, ethical and many other reasons. I also would like to stress that a misconcept does not qualify the person clever or stupid or anything. It is just a misconcept that comes from someone’s personal experience. Here is what she/he was saying.

We use mocks so that we can write tests for units that use heavy services that may not be available when we run the test. It is also important to mock so that the tests can run fast even when the services would make the testing slow. It may also happen in an enterprise environment that some of the services are not available when we develop, and therefore testing would be impossible if we did not use mocks.

Strictly speaking the above statements are true. I would not argue about why you or anybody else uses mocks. But as a Java professional I would argue about what the major and first goal we use mocks for.

We use mocks to separate the modules from each other during testing so that we can tell from the test results which module is faulty and which passed the tests.

This is what unit tests were invented for the first place. There are side effects, like those mentioned above. There are other side effects. For example the unit tests are great documentations. If formulated well they explain better how the unit works and what interfaces it needs and provides than any javadoc. Especially that javadocs tend to be outdated while Junit tests fail during build if get outdated.

Another side effect is that you write testable code if you craft the unit tests first and this generally improve your coding style.

Saying it simply: unit testing is testing units. Units bare without dependencies. And this can be done with mocks. The other things are side effects. We like them, but thy are not the main reason to mock when we unit test.

Unit test life?

You can not program without testing. You write unit tests first and then you write your code. (Well, I know you don’t but just let’s focus on best practice.) When there is an error in the code, first you write a new unit test that demonstrates the bug and then you fix it. After the unit test runs fine the same bug should never ever happen again without being immediately signaled by the unit test.

Later the integration and user tests come. They test the application and in case there is some error the developer fixes the code. If possible and feasible we create new unit tests to cover the case that was not discovered earlier so that the same bug will not slip to more expensive integration and user tests. In other cases unit testing is not possible or would just be too cumbersome and not worth paying the cost when the bug is strongly related to integration or user experience.

This is a working practice that was developed for software creation during the last twenty or so years.

Real life is, however, not that simple. There may be no time to create the new unit tests after a bug was discovered during integration or user tests. You fix the bug and test the functionality of the application manually and omit the new unit, or non-unit but still automated test because creating that is too expensive, would require too long time and project constraints are tight. The bug you fix is serious, high level, show-stopper and this is already the last few days of the testing period. So you focus on doing the right thing: get the job done, fix the bug.

• Have you started to fix the bug we reported yesterday?
• No. We had no time to deal with it. We had to attend to higher level issues.
• Higher Level? What are you talking about? There can no fix be more important than this!
• Then why did you report it as a cosmetic in the first place?
• Cosmetic????? COSMIC!!!!

Sometimes even drop-down lists do not prevent erroneous user input.

Later, over a calm weekend perhaps, you start to think about the case. How come that a serious bug is only discovered at the end of the testing period? Isn’t there a bug in the testing process?

Unless the bug was introduced during the recent bugfixes, in which case there can also be some issue with how the developers fix bugs, there is a bug in the testing process. The tests cover all significant functionality of the application and the test cases that assert the correct behavior are ordered by severity. The test cases that are supposed to discover severe issues should be executed sooner, and less important, cosmetic issues should be tested later. If this was not the case: it is a bug.

How do you fix this bug? Move the test case that was executed late to it’s proper position. It will not fix the bug manifestation that has already happened, the very same way as a bug fix does not remedy the lost money caused by program malfunction. Fix will just prevent causing more damage. During the next release period (well, yes, think about good old waterfall) the regression testing will discover the same bug sooner.

But why do not we create a unit test for the testing process? Why don’t we have unit tests for the processes of the corporate? How could we generalize the idea and practice of unit testing over all aspects of the life?