Approach!

“If you’re not getting results, change your approach.  The best way to get unstuck is to change your approach.  You learn the most from trying something different.  Sometimes this is uncomfotable, but that’s what growth feels like.” (MSDN Patterns & Practices Blog)

Above quote is from J.D. Meier’s blog and I totally agree with this. I have seen people with different approaches. Some people stick to their habits and don’t want to change the way they are working. Even I have seen people arguing against changing approach and even don’t want to listen that their approach is wrong or there is a need of change in their approach. This is the worst thing that I have seen people doing. People even have to pay off sooner or later but they don’t want change, even after failure. They find different reasons, blaming others or subordinates, or the situation. But they don’t realize that this situation is due to their approach.

Approach is the thing that can lead you to either success or failure. If by adopting one approach you get succeeded, it is not necessary that you will always be succeeded by that approach. With the passage of time and changing situation, you have to change your approach as well. One approach won’t always take you to the top. You have to take different routes, with different approaches, if you want to go up the ladder, otherwise your direction will be downwards.

Overqualified Employee is an Asset, don’t lose him

There is a very nice article Overqualified Employee: A Liability Or An Asset? on Rozee. One point I totally agree with and thought I should post it on my blog. Here is its excerpt…

How To Deal With An Overqualified Employee?


Utilize His Expertise

If you have an overqualified employee on the team be sure to utilize his experience rather than feeling threatened by it. His expertise is a valuable asset for you and you can utilize it for the progress of your company.

If you don’t utilize his expertise then he will not be motivated. As author of the article has mentioned here…

Downside Of Hiring An Overqualified Employee:

Lack Of Motivation

… the work will not be challenging enough for him and he will get bored quickly, loosing focus and motivation. When an employee loses focus he instantly starts looking for another job and thus becomes a flight risk.

How to improve quality of your quality standard?

Having quality standards for your organization and project is a must. But putting everything in your quality standard can make your quality standard worse. There are few guidelines you can consider when making a quality standard, but following two are most important I think.

  • Develop a consequence for each quality standard. I like to call this the “Who cares?” test. For each standard you identify, develop a logical, thoughtful consequence that will occur if it is not met. If you and your advisory board can’t identify a realistic outcome, or if the consequence is minor, consider revising or deleting the standard. It’s too easy to throw everything into your quality standards list. More is not always better, so be sure to focus on what matters most.
  • Evaluate the quality standards as a regular part of your project postmortem. Putting practical standards in place is a great first step toward meeting the expectations. So, to ensure that your quality standards continue to pay dividends, it’s important to include a regular postmortem review. Ask questions such as:
    • Were any quality standards ignored? If so, was the consequence significant?
    • Was the product designed with the quality standards in mind, or were they applied after the product was designed and needed to be tested?
    • Did the team take the quality standards seriously, or did they follow the guidelines because they had to?
  • Getting a good read on how project teams viewed the quality standards will help you improve these measures, and over time they will evolve with your organization.
  • There is a good article on Microsoft Office Online providing bit more guidelines on developing a good quality standard and then maintaining the quality of your quality standard 🙂

    How change can bring motivation?

    I always believed that bringing change is one of the key factors which develops people’s interest and keep them motivated. But I was surprised to see that how promoting another person in team can motivate others, specially where situation is worse and people are fed up. Bringing change can charge people up, but we have to see that what type of change is necessary. Sometimes a change can demoralize people, specially when people are already happy with something.

    Another factor to keep your team motivated is to communicate with them and ask their problems, and try to solve it. Again, solving problem will bring change and your team will become more responsible, honest, and motivated.

    What is success?

    Yesterday I came to know how people think about success. A guy was describing what success is and how to be a successful person. His speech reminded me Surah Al-Asr in Quran where Allah has mentioned about successful people:

    1     By Al-Asr (the time).

    2     Verily! Man is in loss,

    3     Except those who believe (in Islamic Monotheism) and do righteous good deeds, and recommend one another to the truth (i.e. order one another to perform all kinds of good deeds (Al-Maroof)which Allah has ordained, and abstain from all kinds of sins and evil deeds (Al-Munkar)which Allah has forbidden), and recommend one another to patience (for the sufferings, harms, and injuries which one may encounter in Allah’s Cause during preaching His religion of Islamic Monotheism or Jihad, etc.).

    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.

    How to setup PHP development environment in Eclipse?

    As I am currently working on Joomla (http://www.joomla.org/) a CMS built in PHP, I came across a very nice tutorial about how to setup your development environment if you want to work on Joomla. Although the tutorial is specific to Joomla, PHP, and Eclipse, but in general it is a very good tutorial and one can learn how to setup a development environment for any project irrespective of technology used. Especially novice programmers will learn a lot from it.

    Author first explained how to install and configure XAMPP, then configure PHP and XDebug to debug the PHP applications. Then author explained how to install Eclipse, setup your workspace, configure it for debugging. Then author created a test project and ran it in debug mode. Then in the end author explained how to install and configure subclipse (Eclipse SVN plug-in) and how to import a project from SVN repository.

    This is a very nice tutorial in general and specifically for those who work in Eclipse and PHP. Wanna read it? go ahead: http://docs.joomla.org/Setting_up_your_workstation_for_Joomla!_development

    Why code bad?

    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.”