|
Acabo de escribir esto en linkedin, a la respuesta de "qué hace que un proyecto salga correctamente (en inglés). Os lo pongo aquí a ver que os parece. By far... robustness is KEY for a success project. And robustness is hard to predict in advance, the project needs some experience and feedback. I assume that you are the real leader of the team, not only the supervisor... my top ten list (in no special order): 1) A process cannot be implemented if the process is not well defined previusly. So, the process and production pipeline should be tested as soon as possible. You will need an expert in the process that you will implement. 2) Develop with facts, not with with abstract ideas. Software arquitects enjoy desinging very common classes, extensible, etc, but they forgot the target soon. So, the interface/methods/etc should be as much realistic as possible. 3) Many small pieces with simple task. At the end, everything goes to linux philosophy... If the pieces are easy, any programmer will be able to optimize that piece, and he will understand it soon. It is hard to get huge robust applications, but it is easy with small code. Complex solution are signals of weak engenieer skills. 4) Be ready to kill your babies. If facts tell you that the key ideas are wrong... they are wrong. If facts are telling you that it is complex, then simplify it. 5) A robust system is the result of a long term process. It must be tested, and the team must be ready to identify what is going bad and well. A couple of days using the system is NOT a test. Only under pressure, a pipeline and a project will be really tested. Dont try to improve the system if you didnt test it before under pressure. If your system works under pressure, it is a complete success, and users will love the solution, because they will need it to solve their problems. 6) Always, always, always you will find many ways to develop the same thing. Facts will tell you which one is better. 7) Refactoring must be done AFTER the process has been tested. There is nothing bad in a 2.0 version, doing exactly the same that the previus one, but designed with all the requisites really clear. 8) "it works" is only a part of the answer. You should ask: how much time do I need to change it? how many resources do i need to mantain the code? how much time in documentation? how much time in user training? is the release time long? If your software "works" but users need huge training, and a big manual, you are wasting their time. 9) Everybody in your team must understand the process. Everybody must understand where are the key issues, so, they will pay more attention to the key parts of your code. They will help the project with ideas, because, they know the process better than nobody else. 10) "In theory" is not enough. Reallity is always more complex, and under pressure, users and delevelopers have not time to waste with your system. So, hacks appear everywhere, bypassing the "theory". It always happens, so, be ready for that.”
|
