Things That Should Not Be Left For Last In Projects
Would you like to avoid having to re-do tasks by completing them earlier? While working on many projects, I spotted things which could cause unexpected problems if left for last. It’s better not to forget about logging, integration and security. Let me know in your comments what other things frustrated you when you had to leave them for last.
15 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівDocumentation and manual tests :)
How do you deal with the documentation? Do you use architecture decision log?
I meant — public documentation. I become unhappy, taking such tasks, and I postpone these tasks until the last moment. But, of course, documentation which is written in an hour, which should be created within days, is awful. And it makes me unhappier. :)
Exactly, documenting your decisions must be a process, I described it in the last paragraph in my recent post techleaderjourney.com/...eft-for-last-in-projects
The conversation of a blind and a deaf. I didn’t say anything about documenting decisions. I told you about the public product documentation. Like developer.toradex.com Creating and improving such documentation was my topic.
Sorry, I get it now ;) Like dotnet.github.io/docfx
Probably, not really. I don’t think the DocFX can help creating the documentation for the Hardware-Software product, especially for the BSP part of it, the documentation for a system developer, not just for a software dev :)
Jaki ciekawy sposób na promowanie bloga xD
Thanks for your comment. Yes, the main reason I’m a blogger is to help people who want to become Tech Leaders. This role, besides being a huge responsibility, making demanding and complex decisions, can be delightful and fulfilling as well. I want to help with this transformation from Senior to Tech Leader. To achieve this goal, I need to promote my blog in different places hoping the content is useful and valuable.
I believe, first and most important is architecture! It is easy to think that on start your project is not big enough to bother about loose coupling, separation of concerns, modular design, etc. But if this is not POC — you project may grow in time. And maintainability and extensibility will become a concern.
The problem is that many good practices are easy to implement and follow from the start. But very painful to apply to the existing code base. For example — if you have code without interface segregation and dependency injection — adding unit testing will require time comparable to rewriting code from scratch.
Another important thing — you always need to remember that you are not writing code for yourself. Imagine that tomorrow some young and hot junior will have to add feature to your perfect code. Will he understand how to do it right? Did you do all possible to protect your code and made it clean, maintenable and extendable without hacks?
So I believe the best thing you need to do early — is to introduce good practices and policies to check them. It may cost you about 10 — 20% additional time for each new code you write — time within estimate precision. But postponing them for later is not an option — because nobody will allow you to hold the developemnt in the middle of the project and spend weeks to introduce practices you missed on start.
You should think big — spending little extra time will allow your project to stay healthy and evolve for years, rather that slowly die under weight of technical debts.
Fully agree with you. Especially, the third paragraph is crucial for me. Everyone in the team should know current Definition of Done, Definition of Ready, Code Branching Guidelines and Release Process etc. It can improve communications and make clear expectations. Of course, the lack of architecture at the beginning of the projects can turn into a nightmare. I recommend here to keep in place architecture decision logs (cognitect.com/...ng-architecture-decisions) and document each decision (for instance CRUD is also fine if we are aware of pros and cons after that It is a conscious decision, not a lucky break)
/help
My thoughts you can find here: techleaderjourney.com/...left-for-last-in-projects
tests )
Thanks for your comment. It is obvious for us but how would you sell the unit test ideas to the business? How to measure this investment?