I've been out of college for a little over a year now, working on a "real" software development project for the past 10 months or so. I have to say, I've had a huge shift in my opinions of how the "real world" operates. Throughout college, I really only worked on some open source projects (mainly ones that I was involved in starting). Meaning, if there were disagreements among members in the group or if certain members weren't really driven to develop, natural selection took place and those members faded away. This was usually fine because there was little to no funding involved, so people left fairly quickly as it became a chore for them. Development proceeded, and everything was fine and dandy.
However, quite a bit has changed since going into the real world. Sadly, I've become extremely cynical regarding my current environment. Let me explain: I've found myself in a highly contract-based segment of the software engineering market. Everything (and by everything I mean ~95%) is driven by the question "is there someone willing to pay us to make product 'X'?". Goals that an employee works towards are defined in the contract, and any specific task an employee works on is given to him/her by the customer. In my experience, this tends to be not so bad because it results in an extremely focused development cycle that is fully dedicated to fulfilling the requirements of the customer. Development (usually) occurs in very well-defined spins in a wonderful, agile manner. Super. This is wonderful.
The downside: competition for said contract. Ignoring how many distinct companies are actually involved on one contract at any point in time, I've noticed a defined line separating the office into two (wait for it) parties (here starts the extended metaphor). For the most part, both sides of the office play well together, and work together for the common good of the project(s). Ironically, at least in my mind, even though I didn't full understand the situation in the office when I first began, I can say without a doubt that I sensed something a little tense. I don't know how to explain it, but I could definitely feel a bit of friction between parties. What this really means for development is that when overlap occurs between different segments of the project or a decision needs to be made as to where functionality needs to be added/changed/removed in one segment as opposed to another, this giant tug of war begins between the parties. The battle isn't simply for who should do it, but for where it should be done, how it should be done, the requirements of said modifications, the tools to use to implement said modifications, etc etc etc.
Normally, I wouldn't say this is problem. In my (potentially) naive mind, I would say this tug of war is a great process to really boil down the requirements of some desired functionality into the basic pieces, determine how best to integrate them into the existing code, and decide what code to write/re-write/re-use. When people are working in a collaborative environment and can set aside their biases, real collaboration can bloom. Falling back down to Earth, I've noticed that this just doesn't happen. Instead of trying to hypothesize what the list of causes is for this avoidance of communciation, I'll try to stick to the visible effect.
- Problem exists for customer
- Identify final solution with Party A and B (we'll assume both parties can agree to the statement "The project should allow users to do X")
- Party A has opinion A on how to implement solution for X
- Party B has opinion B on how to implement solution for X
The real issue comes about in the fact that #3 never really happens. For whatever the reasons are, honest communication doesn't occur 100% of the time which ultimately results in the final product faltering. Party A doesn't like using tool "alpha", and wants to use "beta". Party B wants to implement algorithm "gamma", but Party A had already implemented algorithm "omega" that they think is "good enough". Ignoring the infinite combination of ways to butt heads, eventually A and B stop talking and go their separate ways. B is now unaware of all of the hurdles A has already vaulted, and likewise A for B. Skill and knowledge sets are now completely disjoint. Knowledge is not shared, but instead sealed up into boxes. I'm beginning to ramble so let's wrap this up and make the final point.
The big tl;dr:
There's a segmentation and friction in my workspace that has been prevalent since the first day that I started at my current position. As of late, this segmentation has begun to increase, causing the two parties to communicate, collaborate, and share with each other less. This is, without a doubt in my mind, a firm step down a path where the final product is not going to best solve the problem. I cannot fathom an environment in which an optimal solution is created by developers the abstained from communication with other experienced developers. As much as I can, I plan on keeping this in mind as this story continues to unravel and try to bridge the divide. The day that my ego grows large enough that it prevents me from heeding the knowledge and advice of *any* coworker/friend/acquaintance is the day that I've failed myself as a software developer.