The one mantra I left undergrad chanting was, “it depends.” Translation: for any given problem the solution involves making trade-offs; space vs. time, time …
The one mantra I left undergrad chanting was, “it depends.” Translation: for any given problem the solution involves making trade-offs; space vs. time, time vs. money, quality vs. quick and dirty. Most programmers think in terms of trade-offs, because they are constantly faced with limited resources whether its memory, disk space, or the scarcest resource of all: time. The same cannot be said for the non-techies you work with. This isn’t a character flaw, its just a manner of thinking, most non-techies think in terms of problem, solution, and the solution’s eta. The discrepancy in the ways of thinking mostly manifests itself when it comes to scoping projects. As a developer it is in your best interest to break down a problem and estimate how long it will take you to design, code, and unit test each portion. Hence, it might not be feasible to implement the entire feature for the next release, and it may need to be built incrementally. Non-techies don’t appreciate or understand incremental development, they want a fully functioning feature set with all the bells and requested in the spec. For them delays translate to lesser revenue or an unhappy customer. The burden-of-proof lies on you, as the developer responsible for coding the feature, you need to learn to speak their language: cost. Not in terms of money, but employee time. Its important to help non-techies understand that while it may only take you 2 days to one week to implement a feature, there are hidden costs such as designing the feature so that it is scalable, secure, and extensible, unit testing your implementation, and then of course throwing the feature over to the QA team to black box test it. And if heaven forbid a bug is found, you need sometime to fix it. Setting expectations and communicating the costs associated with implementing each feature also helps non-techies learn to make trade-offs, only in their lingo its called “priorities”.
At the end of the day everyone wants to deliver a quality product to their customers. The challenge is to do so given limited resources, but it can be less arduous if developers understand the problems they are trying to solve, and set realistic expectations for the amount of time it will take to implement and test, and communicate the hidden costs of the development process to non-techies.
