For the past few months, I've been busying myself with my CS degree final project. On this blog post I want to reflect on a few interesting things I'd experienced during the project. Sure there are gazillion of books talking about flaws and pitfalls in Software Engineering but nothing's more enlightening than experiencing it firsthand.
The project was quite large relative to the limited 3 months time frame. So, it's been quite a rough for me and my teammates, but we finally pulled it off with perfect score and a lot of fun. As tech lead for the team, my responsibility covered things from planning the implementation, architecting the software, writing and reviewing code, and acting as go-to guy for the team.
Here are the 10 most important lessons I learned from the project:
On Scheduling
Lesson 1: Beware of Parkinson's law
Must be avoided like a plague. It's really easy to fall into the trap. No matter if you are project managers or team lead, if you are responsible for scheduling, make sure you do frequent checkup and communicate with team members.
Interestingly, I found that people tend to underestimate their true potential. If your team members think you are insane with your proposed schedule, don't brush it off right away. Make sure that enough support is provided for them, put enough pressure and disciplinary, see how things work out and be flexible. The reward from pulling it off successfully is huge amount of self-respect and confidence.
Lesson 2: The best time to start is when you think it's too early
I got this from Paul Hibbitts, one of my instructor on designing usability a few years back. And since then, it has always been my philosophy in thinking about when to start a project. My team wouldn't be able to pull it off if we didn't set to start right away.
On team working
Lesson 3: Team dynamic is the more important than skills
Technical skills can be learned, but not the team dynamics and working habits. I was lucky that my teammates have quite strong character. Each of them have high self-esteem, determination, and great sense of responsibility. During the time when stress and pressure reached its peaks, we were still maintain optimistic view and fun attitude.
Lesson 4: Communication is key
Schedule slips, budget goes overboard, specification has changed, these things are inevitable in software project. For whatever happens, make sure everyone knows and take actions. In a team working environment, success comes from team effort, but failure can come from one's mistake.
Lesson 5: Respect the meeting agenda
During team meeting, it's easily for team members to get tied up on technical discussion and forget about other things. We tried to organize our meeting agenda to cover various important topics including scheduling, implementation, report. As it turned out, we tended to forget about the agenda and focus our attention on technical side more than we should.
Lesson 6: Be a good mentor
At the beginning, apart from myself, the team didn't have much technical background in Java and nothing at all on Hibernate and Swing App framework. Yet, other team members picked it up in just a weekend after I send them useful links on the subjects.
The team UI designer once asked me how Swing would handle events. I could have answered her right away, but instead, I give her a few links to various Swing tutorials. Not because I tried to act as mentor, but I was busy at that time. As it turned out, she came back 15 minutes later and proposed a solution that's better than what I originally had in mind. This is how much you can learn from being a mentor and not simply just giving out answers.
On development
Lesson 7: For an amount of time you spend on design, you save 3 times of that in implementation
We didn't put as much time on design phase as we should have. We ended up having to go back to the drawing board and do rework a few times.
Lesson 8: No matter how far you've gone on a wrong path, turn back
And yet again, we didn't turn back. 80% of our allocated time was spent on the last 20% of the code...
Lesson 9: With great features come great responsibility
Software team usually gets excited on a new project early in the beginning. They would crank up a number of features and overestimate the ability to deliver them within specific time constraints. Some simple rules I use to avoid feature creep syndrome:
- Focus on the requirement
- Clearly separate 'needs' and 'wants' features
- For each of the new feature, carefully think of its interaction and dependencies other existing ones. The higher level of dependency the more time it takes to implement. There are some metrics and methodology you can use for estimation like COCOMO. Steve McConnell's book on software estimation is also a good source on estimation.
Lesson 10: Aim for successful delivery, avoid drinking technological Kool-Aid
Picking development technologies and frameworks for a software project can be a difficult task. Most often, you wouldn't have the privilege of choosing the technology that you and the team are comfortable with. If you do, it's can be equally if not more dangerous.
Each technology from each vendor has unique strength and sets of features. It's also easy for us geeks to go for the leading edge immature technologies. If chosen without careful consideration, the whole team might end up be drinking the Kool-Aid. The project itself turns into a research-oriented development.
Ultimate lesson: DON'T BE AN ASSHOLE
You are working in team for a simple reason: you can't do it alone! So, be nice to your teammates and give them respects they deserve. I believe that as important as delivering result is to have good time working on the project. Communicate with authenticity, respect for others, and an open mind can turn the time you spend on a project to an enjoyable one =) !
