How to kill your time by hardcoding?

My colleague asked me to help him solve an issue he was facing. I sat with him and after spending more than half an hour I realized that someone has hardcoded the server name :@ while we were assuming that we have already moved to another server.

The main thing to realize here is that if we have spent few more minutes in making the server name configurable at first place then we could have saved hours that we spent later just to find out that server name was hard-coded. Not doing this results in frustration, waste of time, de-motivation, brings down the moral of the team, and finally kills productivity and you lose credibility.

Hidden Reasons for slipping project deadlines

There can be so many factors that affects the deadline and project can be delayed. There is an excellent article 10 ways to get a slipping project back on track on TechRepublic explaining the remedies. But in my opinion tips given by the author are where there are already processes defined and a proper organizational hierarchy is maintained, not just maintained but also everyone at its position has its role and responsibilities defined and he works according to his role. At least to some extent. But what when this is not the situation? Let me explain here by first commenting on the TechRepublic post.

Overtime was on the top in that post. Author has already accepted that this is an option when you are at the end of the project, and there are better strategies if you are in early stages of project. I agree with that. You cannot work overtime for a long period. Few overtimes are acceptable. I just wanted to mention this here.

Few other reasons of slipping the project deadline is setting the deadlines blindly, assuming ideal situation and not keeping the buffer, specially when there is a learning curve when you are working on something new.

Another problem is that if there are lots of senior guys and everyone is imposing his own decisions discarding other’s. Having senior guys is good but everyone should have separate responsibilities and no one should interfere with other. Discussing matters, coordination, and giving opinion is something else. Not having this leads to unstability.

Another major big problem is with the management when talking in terms of investment. Besides company’s plans few things are obvious where anyone can see that investment has been done at wrong place or investment is not done where it was supposed to be. Like hiring skilled people and paying them good. Finding cheap human resource does not always work. You should know when you have to invest in human resource and when not. And if you already have good human resource then appraise them before you loose a good resource and someone else steals it from you. Keep in mind as long an employee works for a company, he becomes more valuable asset since he has learned so many things and new employee will take time to learn those things. If you can understand this then you already know that time is money. And if employee leaves in the middle of a project, then obviously there is a big chance of slipping the deadline. You have to put extra resource, reschedule accordingly, assign resource etc etc.

Another one is related to human resource and team. One should have experts and should have responsibilities and roles defined. Don’t expect one to do everything from project management, to design and architecting, to learning, to implementation, to support. Project Manager is one guy, System Architect is another, Developer is another, Designer is another, Tester is another, Network or System Admin is another (sometimes two), and Support personal is one another. If you don’t have enough money to hire all these people then don’t jump into the big business, otherwise you will fail. Start with small and gradually build your team. This is a long term investment.

Besides human resource, other resources are also important, including facilities. Not providing sufficient resources to the team wastes time and at the end deadlines are slipped. Employees also get frustrated. Even a very small resource or facility has its effect. Not upgrading systems, network issues, not providing healthy environment, and even not having standards and policies are the reasons. Having flexibility is something else and not having proper company policies is something else. Not having these demotivates employees and one cannot give his 100% then.

One another important thing is forecasting and future planning. If you don’t have the plan and has approach like we’ll see when that will happen, then don’t be surprised if you fail to accomplish your goals.

When working on projects you should have dedicated resources, not the ones that come on and off. I am typically talking about human resources here. Since working on project and to complete it in time needs concentration and focus. There can be resources who come on and off but don’t assign them critical tasks. Use them for assistance only.

Processes! Just having separate development and testing teams doesn’t mean you are following processes. There are processes for within individual teams as well. If processes are not defined then this is also a reason for not meeting the deadlines.

Besides all this I also recommend reading Peter Steven’s blog post 10 Ways to Save a Slipping Project.

Why code bad instead of clean code?

I was reading the book Clean Code – A Handbook of Agile Software Craftsmanship, Rober C. Martin Series. A section in chapter one caught my attention and remind me of code and reasons that I got for writing bad code and designing bad solution. Now I think this is a good argument against it which I am quoting here from the book.

“Have you ever waded through a mess so grave that it took weeks to do what should have taken hours? Have you seen what should have been a one-line change, made instead in hundreds of different modules? These symptoms are all too common. Why does this happen to code? Why does good code rot so quickly into bad code? We have lots of explanations for it. We complain that the requirements changed in ways that thwart the original design. We bemoan the schedules that were too tight to do things right.
We blather about stupid managers and intolerant customers and useless marketing types and telephone sanitizers. But the fault, dear Dilbert, is not in our stars, but in ourselves. We are unprofessional.
This may be a bitter pill to swallow. How could this mess be our fault? What about the requirements? What about the schedule? What about the stupid managers and the useless marketing types? Don’t they bear some of the blame?
No. The managers and marketers look to us for the information they need to make promises and commitments; and even when they don’t look to us, we should not be shy about telling them what we think. The users look to us to validate the way the requirements
will fit into the system. The project managers look to us to help work out the schedule. We are deeply complicit in the planning of the project and share a great deal of the responsibility for any failures; especially if those failures have to do with bad code! “But wait!” you say. “If I don’t do what my manager says, I’ll be fired.” Probably not. Most managers want the truth, even when they don’t act like it. Most managers want good code, even when they are obsessing about the schedule. They may defend the schedule and requirements with passion; but that’s their job. It’s your job to defend the code with equal passion.
To drive this point home, what if you were a doctor and had a patient who demanded that you stop all the silly and-washing in preparation for surgery because it was taking too much time?2 Clearly the patient is the boss; and yet the doctor should absolutely refuse to comply. Why? Because the doctor knows more than the patient about the risks of disease and infection. It would be unprofessional (never mind criminal) for the doctor to comply with the patient.
So too it is unprofessional for programmers to bend to the will of managers who don’t understand the risks of making messes.”

Breaking problem into code

Let us consider an example. If you have two boxes say BoxA and BoxB, and there are few balls of different colors, let’s say 5 balls (red, blue, green, yellow, and white) in BoxA, and you want to move one ball, say red ball from BoxA to BoxB. What will be the steps? If you can make a flow chart of it then its good, but if you find it difficult to make a flow chart of it then you need to do some hard work to become a programmer.

I asked this to someone and guess how he solved it. Here is his solution. Take out all balls from BoxA, then pick the red ball, put it in BoxB, and then put all remaining balls back in BoxA.

Fine! it worked. But why would you take out all balls if you can only take out red ball and move it to next box?

Let’s move this to programming side. In the above mentioned scenario we will have two database tables, boxes, and balls. boxes will have boxid as PK, name, and other details. Keep it simple so we don’t get lost in other details. balls table has ballid as PK, name, boxid as FK, and other details. boxes table has two records with 1 and BoxA as its boxid and name. balls table will have 5 records with id between 1 to 5 and red, blue, green, yellow, and white as their names, and all balls will have 1 in boxid field which is FK to boxes table.

Now if we adopt the first solution then it will run following queries (these are pseudo queries not actual SQL queries):

– select all balls where boxid=1 (so we can have a list of all balls before deleting them from database)
– delete from balls where boxid=1
– insert into balls values ballid=1, name=red ball, boxid=2
– insert into balls values
(ballid=2, name=blue ball, boxid=1)
(ballid=3, name=green ball, boxid=1)
(ballid=4, name=yellow ball, boxid=1)
(ballid=5, name=white ball, boxid=1)

Or even worse if we use multiple insert queries. It will run from 4 to 7 queries.

Now let’s see what happens if we just perform operation on the red ball and don’t touch other balls.

– update balls set boxid=2 where ballid=1; /* ball with id 1 is the red ball */

Wow, just one query and we’re done! We saved 3 to 6 queries. Imagine this scenario for a high traffic website or any other application, we can improve the performance with a big difference by just implementing correct logic to solve a problem.