Tag: design

How to kill your time by hardcoding?

by Muhammad Jawaid Shamshadin C/C++, C#, PHP, Project Management, Technology, Web DevelopmentLeave a Comment on 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

by Muhammad Jawaid Shamshadin Project Management, TechnologyLeave a Comment on 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?

by Muhammad Jawaid Shamshadin C/C++, PHP, Project Management, TechnologyLeave a Comment on 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.”