A developer is working on a new project. He knew that, company's expenditure on that project is little more than $1.5 million. After some time, he came to know that, his company gets $1 million as revenue from that project. Now, the developer is criticizing the director for accepting the project which gives loss to the company. He thought, whether he should develop the project sooner by sacrificing the quality.
Irrespective of how open the company is, sometimes, developers are not aware of the business intricacies unless they show interest in knowing that information and regularly interacting with the directors. In this specific case, the director wants to get $100 million project from that client, and to show the company's capability, he took this $1 million project. If company delivers this project efficiently, most probably it can get $100 million project. If the development team sacrifice the quality, and if the customer does not like it, they can lose $100 million project.
Developers should not worry about the profits and losses, and should always strive to do the project efficiently in the given time frame. If they have capability to give suggestions to the directors, then they should learn what all is going on, and see whether their ideas can work or not and then help them. Without that, it would create only problems.
A program manager is the one, who is supposed to give requirements for the system. Sometimes, Clients give the specification for the environment of the system. If clients do not specify any environment, then it would be decided by the development team. Based on the environment, Development team decides technology, tools and design.
Program managers can always give their suggestions on environment, technology and design. If they want to command, then they should come and help development team in the entire development phase. If they don't give suggestions, but command the development team to use some technology because the marketing documentation of that technology says, it can do all those, then the project will face fatal failure. If they give suggestions, it should be very clear and concise. Not just, "documentation of this technology says that".
One real example:
There is one process which stores files, and there are multiple processes which reads the latest files. The problem is how do we design the system in such a way that, there is no synchronization problem.
My solution was very simple. Use Database. I did not stop there, but explained the following as well.
Set the transaction isolation level to read committed, and always insert a new row in the database for new files with the time stamp. The processes which reads the data will read the row which is having the latest date. Since, it always gets the committed data, we don't need to maintain any synchronization in our code.
For anyone who has some understanding of the database can understand the above. If they are not aware of the databases, then I can tell in little more detail in this case. I have got many suggestions from many non-developers that use xyz, use abc. But, they never elaborated it how to implement it.
Many times I feel like saying, "If you can explain in more detail, please explain. Otherwise, please shut up. I will design it on my own.".
Some times few developers reject to implement few features and fix few bugs citing reasons that after code freeze, we are not supposed to fix bugs. I could never understand their problem. I tell them how much time I am going to take to implement it. If they are fine with that time, I will do it. If they feel the returns is less when compared to the effort, they will not ask me to do it. I take the tasks depending on the priority of the Program Managers.
Probably customer is frustrated because of one alert in the first screen rather than the crash of the application in one very corner case scenario. Program Manager knows what are the priorities for the customer, and I implement in the same order. Why should I interfere and say that, crash is more severe than alert. So, I fix only the crash, and not the alert. That does not make sense.
Don't interfere in others work as long as they are delivering what they promised to deliver. If they fail in their promise, don't command on what should they do. Step in their shoes, understand the entire situation, find the reasons for the failure, discuss the solution. If they just say it does not work, and if you are not convinced, do it yourself and understand the problems.
Demand freedom in your work, and don't interfere in other's work without having enough knowledge.
Posts
No comments:
Post a Comment