This will be an evolving post, containing all the learnings I had(or will have) while building and managing software projects.
The list is totally based on my opinion and experience. Here it is:
Communication is really important.
You might have heard it many times already, but the very fact that you hear it so many times is because it is really important.
- Keep communication as open as possible. Use a medium which is easy to use for everyone and especially easy to track and find information(you will need it a lot).
- Don’t be afraid to ask. A question may seem like wasting time right now but right questions save the project. A stitch in time saves nine.
- When asking questions make sure you make life easy for the one who is doing the answering.
Example: Instead of asking “I don’t really understand what #1.a means”, give whatever you understand as a statement and ask if this is correct understanding. So a better question would be “Does #1.a mean that, the user will first register as a supervisor then only he can make the changes?”. Now the answerer has to explain only if your understanding needs correction, otherwise they can simply say “Yes”.
- Discuss roadblocks ahead of development. If you feel something can hamper the development, do share it.
- Always encourage discussions, especially when you are starting with a project. You might feel that discussions take up too much of time but eventually once everybody understands the project and each other, the discussions will become shorter and more to the point.
- Document as much as possible. Put your discussions into a document as often as possible. Putting things into writing help you with the thinking as well as keeps a history project evolution.
Technology doesn’t always matter.
You might look at the market and say that you need to move from your current tech. to this new “hot” thing in the market. But what I have got to know is working with the latest and greatest might help, but the thing that is more important is your ability to solve problems and an open mindset that is willing to make improvements later.
I was also torn between which technology to work with next, until I got the opportunity on work on projects, which were using relatively older tech stack but they were really well engineered, the architecture was very well thought out and they were handling large user bases.
Also, now I believe that first you need to get started, build something that solves the problem and then when you are hit with scalability issues, tackle them one at a time. We improved the architecture and small parts of the application as the demand on the application grew.
Set the standards with the Client/Project Owner
- Not all the people who want to have a product built for their business are tech savvy, so they might not be exactly clear on:
- What the technology can do, it’s capability and limitations.
- What exactly they are looking for. In such a scenario, the best way to make sure you are building something that they really need, is by setting right expectations, keep track of development and keep the client aware of it.
- For this you will need to make sure that the client agrees to the following:
- They will need to communicate daily(or some set time) for clarification of doubts or any queries.
- They need to keep track of work proactively, by making use of a project management tool or something that they are familiar with. A project can’t be built successfully if the stakeholders are not actively involved with it.If the above two can’t be satisfied by them, then I would say you should be charging them more, as a good amount of effort and time will be spent in chasing them.
Never work with people you don’t like.
If during the initial meetings and project discussions, you figure out a particular behavior of the client/team that doesn’t match with your core values, then it is time for you to think. Think if you really want to work with them.
I have faced this with both client and team, you have to face these people daily, maybe even for the major portion of your time in the day. So if you have to force yourself to be working with them, then you are going to waste a lot of mental energy, which you could have used instead for your work.
Delay signing the contract unless you understand and agree to the complete scope of work.
It’s difficult to have everything agreed upon and written down, but you still need put in your best effort to be as clear as possible and set correct expectations. I had a client write something like this in the requirements document “The application handles process X first and then will handle all the processes”. Handling that process X was the major chunk of the application that we were going to build and had agreed for. For this application “all” meant another 26 entirely different processes!!. That was a whole lot of work hidden inside a single sentence.
Scope of work and requirement documents are filled with such ambiguity. Try to iron out as many ambiguities as you can, as these ambiguities might either push the project down the drain or strain your relationship with the client(or maybe lawsuits in some cases). Make sure the document doesn’t make you promise more that you had thought of delivering.
Break the project into smaller deliverable parts, which you can show to the client and get feedback.
I made this mistake, the project was divided into the “Admin” and the “User” section. We further divided the project into tasks and the team started working on it. But what we failed to do was to show it to the client at frequent intervals and getting regular feedback. We waited till we finished the complete Admin section and showed it to the client. It was a complete disaster for the following reasons:
- It’s really difficult to explain all the functionality and it can span to meetings that take multiple days to explain.
- It is very difficult to someone(client) to comprehend and understand such amount of information.
- If you diverge from a feature request, by the time you take it to the client it might be something that is totally off from their expectations, this might lead to rework, delays and frustrations.
When giving costs include everything.
There will be a lot of unknowns, changing requirements, travel, meetings many other variables. Make sure you make the client also understand all these and take this into consideration as well when giving them the final quote. “Hours of work * price per hour”, usually wouldn’t cover all your expenses.
Have some form of testing in the project to ensure quality.
I have worked on projects that had testing and which didn’t have testing. All the time the projects which had some form of testing were of better quality. Testing can be in form of Unit tests, automated test or even manual functional tests by a QA person.
In my personal opinion, unit tests along with peer code review can really help with quality of the deliverable and this reduces redundant testing and need of another team member solely for testing.
Evaluate current state when taking maintenance Projects
Not every project that you get to work on would be brand new, written off from scratch, you will sometimes land maintenance projects or partially complete projects.
When going into such projects remember to:
- Analyse the current state of the project. Check:
- Is the project really in the state that the client says it is?
- How well is the code structured?
- Does it have documentation (code, user)?
- How well does the client understand their current requirements? If they don’t have clear idea your job is not going to be easy.
- Research the technologies that are involved. The client says it’s a NodeJS project and you have done plenty of NodeJS work, it’s still not a good idea to just go ahead, unless you check other things like:
- Where and how is it deployed? Azure, AWS, Firebase – All come up with their own nuances
- What are the sub technologies used? PostgresSQL, Mongo, MySQL, Firestore
- Since this code isn’t yours, don’t assume the timelines and esitmates based off how you would have done it. Add buffers, as you will need to spend additional time to understand structure and certain coding patterns