In the software industry, people, especially managers (who almost always don't understand a thing about software!) love putting processes in place. Processes for designing, processes for coding, processes for testing and even processes for incorporating new processes!
Unfortunately, things are easy to do when the team sizes are small. At that time you don't even need too many processes. When the team size starts increasing, that's when things get difficult. Processes are not understood and not communicated properly down the ladder. That's when things get messy.
Let me give you an example from my career. We were starting a big project (not the BIG project, just simply a big project). We wanted to make sure error messages were standard across the application. For example, if the user did not enter some important information while creating a customer, he got a message, "Fields marked * are mandatory". If he did not enter some important information while creating an item too, we wanted him to get the exact same message.
For that, we mandated that every error message goes into a common text file. Whenever you want to show an error message, pick something from that file unless it does not exist in which case add a new message which others will also use in the future. Simple enough, right?
Wrong.
For the first few weeks everyone followed this. As the team started growing in size, however, people simply used the error message file as a dumping ground for error messages. They would add whatever they wanted without bothering to check if an appropriate message already existed. As a result, the entire meaning in the process was lost! If anything, the program would run a tad slower than otherwise because of the overhead of picking up an error message from a file without the intended effect of consistent error messages!
So, as team sizes grow, it is very important to keep the processes being followed very simple with regular checks to ensure they are being followed in the manner intended.
Comments