What your Software House will never tell you
During these 9+ years since we founded Divante, we have come across many Software House companies. With this in mind I decided to describe few myths still present in the world of business software. I believe my subjective opinion can be helpful to those who enter into cooperation with an external IT contractor.
We employ Seniors only
A good company focuses on the employees’ development. Companies known for their good performance over many years (e.g. McKinsey, Google) stress how important the intelligence of their candidates is. Good companies prefer character features and innate skills over knowledge and experience.
Knowledge and experience is acquired faster or slower. Intelligence, empathy, honesty, team play cannot be taught or it is extremely difficult to teach these skills. A good team, as a good company, consists of more and less experienced people, so that it is open to innovation and at the same time benefits from the knowledge already acquired.
You don’t pay for the PM/SCRUM Master’s time
If I were to say who the most important in the team is and at the same time has the worst job I’d say that it’s a PM. A good PM will always attribute the success to the whole team and a defeat to himself.
A good PM is scarce and worth big money. He is the architect of the business success of the project, he is the one who finds the optimum path of the project implementation.
Acquiring, training and maintaining a PM is very expensive. Companies that “give PM as a bonus to the team,” tell you something that is exactly opposite of what I wrote. I cannot imagine how we could give our best people “as a bonus”.
You don’t pay for a PM only if, well… he/she is not worth to be paid for the work. Talk to the PM who is to carry out your project, ask for his resume, check out how well the conversation goes between you.
Relax, we have procedures
In aviation, statistically most accidents happen during takeoffs and landings. Two moments when the plane is subjected to the most overloads. At the time of landing adverse factors may be fatigue and potential human errors — in the end, it is not easy to hit the 10m wide runway from a height of 10 kilometres. The same is true of software development, key elements such as issuing subsequent versions (deploy), verifying the source code (code review) define the stability of the software. A poorly conducted deploy may ruin weeks of work of the whole team, because the system stops working for many hours and, for example, it cannot be restored in the next version. It is therefore important to have procedures and automation. When a company is small, it often does not have the resources to take care of it in the right way. It is worth to talk about the procedures before the work begins.
You don’t pay for the tester’s time
The story is similar to the one with a PM. There is no way to have a good tester included “in the price of programming.” It means that programmers in their free time test their code… which means that they do not test it, and the customer becomes a tester.
Professional, systematic and slightly mischievous tests are the best vaccine to immunize your firmware. A second version of the story about a tester’s time includes an episode of unit tests of a code. Unit tests are very good and should be written. A code tests a code. It is easier to develop the software that has such tests as they immediately find errors introduced to other places of the system which operated prior to the change. But such tests are not enough. CPU tests, interface tests to assess intuitiveness and finding all cases of the UI behaviour on different devices has been and still is the people’s job. Testers are important. If the company does not provide testers, a customer becomes one.
It is simple, no specifications or graphics or mock-ups are needed. Let’s act!
Software companies, managed by software developers are often tempted to move as quickly as possible to what they do well: i.e. to programming. Let’s buy a template for $100 and let’s get down to business. Of course, sometimes actually a shortcut pays, but not for serious projects. On the other hand, it is like executing a function without specification — even the basic one, not to mention the mock-ups. It is easy to see how our vision is different from the ideas of developers and an attitude that “a function is ready and works” often means that it works on a computer of a programmer in its simplest possible form which the normal user is not able to understand. Such things come out after the completion of the development, i.e. at the worst possible moment, when the change in assumptions will consume a lot of precious time. In an e-commerce the temptation to shorten deadlines is always predominant. Time is money. However, sometimes it pays not to hurry too much. An analyst should be present during the development work, which at first glance appears to be an increase in cost. In practice, it reduces the project’s budget.
The system is almost ready
Without internal testing, acceptance testing, performance and security testing and sometimes also a soft-launch (a public launch of a limited number of users) it is hard to launch a new product. E-commerce is not just the software but also the processes, people, other systems. It is good to test them in action.
The deadlines we are given by the IT department/Software House should be carefully discussed. What does a date on the schedule mean? Commissioning to testing (the completion of development work) or actual run? Where does the schedule include user testing, security testing, a period of stabilization, and so on? Here there are often misunderstandings, which can result in dire consequences. Programming work cannot be easily speeded up. If we don’t understand each other, if we plan marketing activities at the wrong moment, we can throw money away. The same risk includes planning launches of new products just before the season. It is also good to do cyclic (2–3 weeks) product demos to independently assess the extent to which the product is finished.
We work with the latest technologies only
If a CEO of a Software House is a practicing programmer he will seek to use the tools in the beta version simply because he likes new technologies. It is of course very cool that a person is passionate about his work. However, technologies in pre-production versions are subject to a giant risk. Usually the changes that occur in them are large and entail a considerable risk of incompatibility.
For this reason, we are very cautious in recommending customers each version of the software with a round number on it. Instead of a version 2.0, we definitely prefer the version 2.1 :)
P.S. We are building our own Startup inside of our very own Software House :) — If you are interested in loyalty programs, we will be more than happy to share our experience and present you our Open Loyalty solution.
→ To hear from me in the future, subscribe to my monthly newsletter (by Revue).
