Silver platter and the doom of custom made software

Silver plattering is a made up verb that refers to giving to the customer more that what is in the scope of the agreement. Basically, you give them your work for free while smiling, you give them what they want in a silver platter.

As any good negotiator might tell you, it can be a good deal if by giving a little you get something else, but it can be the doom of a project if the silver platter starts and never ends. When working in projects, be aware of the risk of silver plattering. I  sank a 7 year old company just because I was not paying attention to it. Believe me, its a high risk.

The expectation that the contractor change indefinitely a software is quite common in organisations that don't have mature processes and don't have a clear understanding of software development practices. It basically describes most organisations working in a undeveloped software market, Colombia for example.

For example, they want the software to fit the process, but they keep changing the process and expect you to develop the change again and again. One that is happening to me right now is that the requirements are given to you with little or no details, for example lacking special cases or precise data that needs to be saved. Then, when the testing starts you are expected to change it again and again for not being a good psych and developed exactly what the customer had in mind but forgot to write down.

What to do? Its as clear as water. Don't give your work for free, no matter what happens. It you loose a client because of it, it might be better for you. First, be sure to include in the contract a clear definition of change and defect. Second, include in you plan a specific milestone for client approval of the requirements and don't start development until you have a valid signature. Then, stick to your process like a fly to honey.

When asked to do a new change because its the "last one", just say no!

Why commit to quality?

Colombia does not have a developed market for software. In most companies the person in charge of buying software is the same person that buys the soap, and buy it using similar criteria.

Quality in software is not understood, and developers have to do not one extra mile, but ten extra miles just to have them accept simple suggestions to avoid petty requirements that will affect significantly the maintainability of huge applications. Most clients haven´t even heard of maintainability as a concept.

You can loose your mind trying to explain the difference between a defect and a change and why you will correct defects but will not implement changes for free. And the concept of controlling changes seems to your client as a bad way to ask for more money.

If complete mess is the rule, why bother implementing a costly maturity model to guaranty quality in processes and products for clients that will not appreciate it and consider it as bureaucracy that increase the cost?

Just because you know maintainable and reusable software will save you money in the log run. Eventually you will move into the maintenance phase or build a similar system and the fact that you can reuse the documents, design or code and make your life easier will be worthy.

Estimations

I remember the first time I heard about Delphi Estimation*. It was my first undergrad course on software engineering. I couldn't stop laughing for a while, how can you base the whole project plan on some persons guess? It sounded so stupid, I kept making jokes about it for a while.

Many years later I found my self having a great deal of respect for estimations based on experienced persons "guesses". Delphi method just growed on me, without me even noticing.

I can now see at a proposal and just know if the estimates are good or not, by heart, I just know. During the last decade I acummulated experience and I am able to classify requirements by risk, know what can be done fast and where the programmers are being just too optimistic, in mi head in minutes.

But this gut feeling wasn't given to me by the gods as a gift, it was built with hard work. I have records of times of the work I have done, for years. Every day I record how much time I spent in each project or activity. Not histericaly, with seconds, but just a rought count each day. Every month I take an hour to summarice it and check if my estimates were correct when I planned my activities. Some times my estimates where acurate, some times they weren't. I learned from the mistake and managed to improve my estimates for next month.
I then started doing the same thing with other's people's work. I created a way to classify requirements by complexity (a personal simplification of the function points, that latter learned, are called use case points). I used to estimate how much time a team needed to develop a set of classified requirements. Then I measured, and compare my "guess" to reality and learned from the mistake. I made this for years and still do it, every day, even with the smallest simple task (like checking expenses from a trip, or reviewing a report).

I learned this wonderfull trick in the same class where I learned the Delphi method. I was "forced" to used the PSP (Personal Software Process) that includes keeping an engineering journal with notes of your work and time taken by different activities. My journal was then a ridiculously pink Hello Kitty notebook, now I just keep it all in google docs files. I will record in a while that this post took me about 40 minutes to write (including finding the magic eight ball picture), and hope that after the 5 minutes it took you to read it, you are curious enough to check the PSP and keep a journal. Believe me, its worth every second spent on it.


* Sorry about including a Wikipedia link as a reference, couldn't find a better link to explain the Delphi Estimation. If you have a better reference, please let me know, I will gladly replace the link.

Careful with the language and the ego

Have you ever been annoyed at a dinner party with a lot of friends from some other profession (say Lawyers, Sport Broadcasts, Musicians, Physicians or any other), when they just assume you understand their terms of know what the hell they mean? Well, don't do that to others! Have this in mind, especially if you are the Analyst in charge of gathering requirements in a Software Project.

Let’s face it, most people don't have a clue what requirement elicitation is. It's even less probable they know what a use case is, or understand what a business rule is for you. But if they don't understand you, and because of that the requirements come out wrong, it’s your fault. And I really mean it!

You can't go asking "give me the business rules" or "what type of data is this? varchar 100?". Your mission, since you accepted it with the job, is to learn their terms, their language, and then translate that into software engineering dialect so your development team can build it.

In a requirement elicitation meeting, the star is your business expert, not you. The one with the sole truth is him/her because it’s his/her problem you are trying to understand and solve. Don´t call use cases use cases if you know it confuses your user. Call them screens, forms or whatever they call it. Don’t refer to the fields in the form, ask for what other little boxes you need. Don´t ask how many concurrent users will there be, ask how many people works in the system at the same time.

So far, we have solved the language thing. Let’s go to the ego part of this post. If you are like me, cocky because you know you are really smart, well... remember that part of being smart is being able to adapt and behave according to the situation. (If you are not cocky, but humble, well good for you, but still remember to behave in a smart way).

In a requirements meeting, it’s very tempting to come up with a really new and smart way of doing things. But, the truth is you don’t know your client business that much, and you don´t know the organization or all the regulations. Maybe your way is really cool, but there is a very good chance it’s not appropriate for the specific need. For example, people don’t like change, and if you want to force a thousand employees to change the way they do simple tasks in the information system that works just fine because you want to show how smart you are, well, that might not be the best ways to go.

Remember to listen, ask properly, make sure you really understood, and remember that the Analyst role can decide if a software project fails or succeeds.

“Sorry, but I won’t tell you how much it cost, nor will I start the project right away”: When clients want to close a business but you know it is a bad idea…

When selling, the whole idea is to close the business as fast as you can. But then again, Software industry is not like any other business. If you are interested in building a confidence long term relationship with you client, sometimes closing a deal is more a curse that a blessing.

Custom software is expensive. It requires a lot of effort, translated into many engineer hours, translated into a lot of dollars. Still, if done properly, custom software can solve many client problems and potentiate their business. But if the software does not reflect the real processes, does not allow the users to actually do their job and even make it more difficult then you are just expending money to lose some more money.

Process analysis and optimization is the first step before even talking about building software. Some clients understand it and will contract you analyst team as consultants first. That is always the best way to go. But if the client is new at these, he/she will try to force you into giving a price and time for the development before the processes have been identified or a scope has been defined. Don’t go for it, even if it means losing this particular deal. If you don’t go for it, someone else will, they will mess up and the door of the client will be open for you a few months later.