My recent Uni project team faced staks of problems recently when it came to synchronising and developing different areas of our system.
There were a lot of lessons learnt by all, I’d like to put down here my lessons I received:
– Make your design clear at the beginning. Ensure that you have Class and Sequence diagrams that tell you what needs to be written by you and tell others in your team how they can interface with your work. A method signature in a class diagram represents a contract to other developers.
– Even if you haven’t implemented all the methods you were assigned to write, others waiting on your work shall be able to use your design and mock these objects in there own tests.
– Errors will always occur. There will be errors in logic, errors in syntax and errors in integration. Usually you can pick up errors in syntax before you submit your code. Always expect errors in integration but provided that you right to the interface agreed on in your design and only make changes to those interfaces when agreed by all.
– Make a time to discuss far-reaching changes that affect the whole project and architecture of the system. Don’t implement changes you see fit without advising your team in advance of those changes, and then allow time to discuss the changes before implementing them yourself.
– Don’t change other people’s projects. If you need to change code that interfaces with yours, pair with the programmer that wrote the code.
– If using a version control repository, commit often to keep changes up to date.
– Likewise, don’t check in code modified by someone else as your own.
– If someone discards the above without good reason (a deadline is an excuse, not a reason – one that I’ve shamefully used in the past) and provides code to the repository or rest of the team, discard and rollback to the previous version until changes meet standards and are agreed on by all the team.
– Meet as often as possible and provide updates about what troubles you.
– Document often, give your objects, methods and variables meaningful names.
– Get everyone involved on all decisions, ensure no one is left out. Its likely someone will stay in the shadows if you treat them that way and they can be the ones with the best opinions and critique. They will also not state their objections which is important because they’ll loose faith in the project and when it comes time to deliver, may not come through, simply because they can’t find and are not motivated to complete a task they dont believe in.