Software Engineering Round 4

• Software Engineering Project: Round 1
• Software Engineering: Round 2
• Software Engineering: Round 3
• Software Engineering Round 4

I am writing the last post in this series a while after we completed the round partly because I was busy and partly because I was very frustrated and angry at the process and the experience in general. This round was the implementation round so we were split into teams each given a module or responsibility in the project and a deadline.

The Danger of Expectations.

I am an optimistic realist which is kind of unfortunate because it means that I have high expectations but also realize that those expectations are not met very often. Despite the fact that I know this, I still continue to expect more of events and people than I should. After cooling down about the experience, I am now again in a position to reflect on the experience and to learn from it.

The Things That I learnt ( and Was Reminded of Again )

Things will go wrong (tm). The team leader of the integration team did not participate in the project. This lead to a lack of direction and communication. This vacuum of leadership was not filled by the project management team who I feel should have lead in the first place. This forced one of the integration team members to take the lead. This was unfortunate since none of the other team members including the one forced to take lead was natural leaders. What it basically boils down to the whole project had little leadership and started late as well.

Leadership is very important. As I noted in an earlier post that task division and communication was difficult. This difficulty is only increased as you add more people and complexity. This is where the leadership has to come in and give a unified focus and direction while facilitating communication and enforcing interim deadlines along the critical path.

The critical path is important.  This is kind of obvious but should be said: you should focus most of your time and energy to insure that the project continues along the critical path. If this means that some other teams have to sit and do nothing so be it. I also think that all the people working on the project should be aware of the critical path and when and where they are on it and the importance of keeping it going.

Deadlines are not bad. Deadlines may seem to be evil and against you when you are struggling to complete them but fair and reachable deadlines are great for getting people to work and signalling the expected pace of the project as well as measuring the actual versus expected progress. The lack of short term deadlines removes the immediate necessity in the minds of the students, which leads to procrastination.

Making people understand technical direction is hard. None of the people working on the project had used the framework that we had to use before, so we had no idea what the best practices were. This did not seem to bother the people, but I don't know why not. After doing some research and talking to the lecturer and some of the other students I was comfortable with my idea of how the project should work on a high level. I tried to explain this to all the other teams and they seemed to understand. They clearly did not because the next two times we met to talk about problems and design, it became clear that they were not doing what they should. The thing that bothered me the most was that I was not using weird designs or anything; I was using standard architectures and technologies which I repeatedly explained and named to insure that if they had any questions or doubt they could Google it.

Management Methodology

I am starting to think that there are two kinds of management or leadership that you can use. The first which is the micromanagement kind where you give the workers exact instructions which they should follow and achieve in a set amount of time and it is the manager's job to see that they don't slack and achieve the goals. The second type is when the leadership set some goals and objectives that are given to the workers which they then achieve by whatever means they see fit.

I think that the methodology that is being used is based on the type of workers that you have. People that work well under the one kind does not function well under the other. In fact I also think that once one of the methods are chosen it shall continue to be used for good or bad because it will displace any workers that do not work well under that methodology.

I don't think one method is better than the other overall, but definitely in some situations. It would be great if the leaders could be able to identify the situation and manage accordingly, but I think that would be very difficult.

A Sacrilegious Thought Arises.

The fundamental thing that I have learned from all this is that the biggest issue in projects are not the technical but the human side. Things like communication and management along with selecting the right people to do the right jobs are far more important than if the right architecture was used or if the project was developed with agile techniques.

This is quite frightening if you consider that in our 3 years of study this part of our professional development is never highlighted; not to speak of being taught.