First of all, this article is a completely reflective post that focuses on my past mistakes, just talking about what I might have done differently. Some readers may know better ways to do this, etc. However, this is only based on my experience, so I would appreciate it if you could keep it warm.
If you get thrown a project one day, be prepared.
That may not be the best way to put it. But when a project is thrown at you one day, it is usually because the project is not going well. If it is a simple staffing increase, it may not be. But if you look around and see that your predecessor is missing, the odds of going to hell are high. In such a situation, I would say to run anyway. If you can't escape, you might as well go buy a sleeping bag for the season. A sleeping bag is the safest way to sleep on an office chair.
Be the first to check for test codes
When you take over a project, the major difference between you and your predecessor or your team is not coding skills, but domain knowledge. Clients tend to lump us all together as engineers, so they don't take into account the difference in domain knowledge that your predecessors have accumulated since the early days of development and their understanding of the current code. Therefore, they make demands based on the same assumptions as before, such as development time.
The test code is to fill in these differences in experience as much as possible. Therefore, when you take over a project, the test code should be the first thing you look for. If you cannot find the test code, you should refrain from changing the code. Then, after passionately talking about the dangers of the current situation, tell them that they should prioritize writing tests first or refactoring now. Because we can't guarantee that it will work, and there is a possibility that another function will break without our knowledge. Besides, by writing tests and refactoring, it is often possible to get a sense of how the code was intended to be implemented. If you skip this step and proceed with development, and a bug occurs, it is not your predecessor or your customer who takes responsibility. In the end, it is you. Wouldn't you like to go home every day?
Don't hate the code. If you hate it, rethink how your project is progressing
The most common cause of project flame-outs is often an overloaded project progressing faster than they think it should. Especially in agile development, for example, there are too many feature requests from the customer, and the requests are carried to the engineers without being discarded. That is natural. If the development time is fixed, the customer wants as many functions implemented as possible. I would probably do the same.
However, just like a conveyor belt in motion, if the speed is not properly adjusted, the amount of work per iteration will increase many times over, and eventually, we will choke ourselves. Let's act now to slow down the conveyor belt.
Customers don't know what's in the code
Customers only know what they experience firsthand, such as whether the software is working properly. In other words, they have no other criteria to evaluate software. However, it is not always the case that the part of the software that you are in charge of is the easiest to evaluate. This is especially true when you are working on the back end or on a large function. In other cases, what looks surprisingly simple from the client's point of view may actually be based on an unbelievably complex process. No matter how hard you try to explain the difficulty of the process to the customer, they will never be able to empathize with it. This is not surprising because they are not engineers. If you are ever told by a client or your boss that you are unappreciative, calm down and smile back, because there are people in the world who feel the same way as you do. At least I am on your side.
To achieve functionality, you need to broaden your vision.
With legacy code, you don't know what's going on in the first place, so trying to add a new feature often doesn't work the way you want it to. In fact, you may think it would be faster to start from scratch. But reality is merciless and will not allow us to do so. Perhaps, though, if we wait 20 years, it might be possible.
In such a case, let's just try to find out if there really is another way to realize the request. It is okay to take the plunge once and move the data out of the current application and let another tool handle the process. There must be other ways to achieve the objective.
And always keep the following thoughts in the back of your mind." The engineer's job is to provide the methods and things to solve a problem. And we should not determine for ourselves the extent to which we look for solutions. Because we are so desperate that we only see what is in front of us."
Are you sure you got that estimate right?
When you are asked to estimate a feature, are you sure you are getting the correct estimate? Remember that software development estimates are based on the uncertainty of the system. If you think you can do it in 10 days in your estimate, you should actually estimate 14 days or around. The reason for this is that in many cases, the actual work is different from what they imagined after they actually started working on it. When asked, "Will it really take that long?" They will be convinced if you tell them that there are many uncertainties and that you want to give them plenty of time to work on it. Besides, they will not blame you if the work is completed earlier than you imagined, so there is no disadvantage in estimating more than enough time.
Don't let them throw away the business logic
It is a common practice in contracted development to have the business logic for a service developed by the client thrown to the engineers. This is not so common in cases where the company is conscious of digitalization, such as when the methods it has cultivated in-house are incorporated into software. On the other hand, it is very common in cases where the client wants to create a new service. In such cases, even the clients themselves do not have a clear idea of what they actually need to do and how to put it together to create what they want to create. And the engineers are forced to think about the process. And in the worst case scenario, the product is not at all what they had in mind.
Furthermore, not knowing the logic of their business is like driving a car without a driver's license. It would be unwilling for a developer to proceed with development knowing that the worst possible future awaits them. So, let's help our clients to think about the logic together with us. There is no need to use complicated terminology. You can use a ubiquitous language that is a common language between the customer and the engineer. Anyway, help the customer to understand how the software system works and to think about the logic on their own.
Top comments (0)