I've been thinking for a long time about what I should write for my first post. Some say the first step is the hardest to take and so, in order to start the journey, I'm typing this one regarding a topic that bothers me each day.
I'm not particularly comfortable writing, neither do I have any in-depth technical knowledge and passion to write about code or some framework with enough confidence. Instead I decided to share my perspective on the joint venture between coding and business, given my short 4 years of experience as a professional in IT, which has always intrigued as well stressed and frustrated me.
Short Bio
I'm 24 years old.
I started as a QA Engineer writing tests as a consultant in Lisbon, transitioned to Java development while in part-time, returned as a QA and reached the point where I'm at now, developing full-stack for a company using Angular and Django.
I did most of my studies while working, and last year I completed my master's degree in Computer Science in the University of Lisbon.
Clash of characters
I've had the privilege of cruising through a couple of companies, from smaller to bigger ones, doing development work or quality assurance, while belonging to a team striving to produce a piece of software.
By crossing different scenarios with those roles, I began to realize the wall that exists between the development team and the software stockholders. The underlying motive as I see it is the following:
Although they have the same ultimate goal, each party's perspective on software is different
A developer, much like an architect or an artist, wishes to build the most qualified software, where quality is mirrored by the way the code base was orchestrated. The decision-making mostly regards efficiency and involves thinking 2 or 3 steps ahead, like a chess player would, with the goal of minimizing the impact of future changes on the code.
As a manager or a product owner, the ultimate objective is to obtain a qualified product, where quality is mirrored from the profit it generates. The decision-making is done in regard to deadlines and business opportunities.
Both desire the best software to be built. So why is there in practice such a misalignment between each side?
Common faults
The understanding of this mutual symbiotic relation between developers and business side entities is, from my perspective, the secret to a healthy and successful software company.
Developers tend to fall pray to the perfect code temptation, which I consider as the most common fault that we developers do. When going down this path it is common to hear the word refactor, which comes by very often, seemingly as a good indicator of quality software, which it can be, if not done all the time without regard for the outcome.
Once in a meeting I was having, the Project Manager arrived very upbeat and uttered the following words: Client A said he really wants feature B for yesterday. Make it happen for next week. Similar variations of this statement seem to come by very often.
How should a team react to such words? A statement like this makes it impossible to reach a compromise on each end. If said feature can be plugged in gracefully in the code base, maybe it does not take much effort other then switching the scope of work of the team, but if that is not the case, whose fault it is when the feature is poorly delivered or not at all?
I consider being result oriented and objective as a good trait for any manager, and on the same measure I believe that any developer should be conservative and strategic when coding. But too much of anything is not good for either, I reckon.
When the desire for results trumps the search for an agreement, or when the desire to code graciously forgets the final goal of the product, a feeling of frustration tends to rise through, striking the motivation of the team, consequentially hurting the development of the product.
P vs NP
This issue has always split my opinion given that the balance line is not and will never be clear, as far as I can tell.
If a company does not meet business needs and requirements no profit will come in for their employees. But if a product is not built responsibly who will want to buy it?
Could this be an NP problem?
Top comments (0)