StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Using a variety languages vs maintainability is simply another <em>design decision</em> with <em>cost-vs-benefits trade-offs</em> that, like any design decision, need to considered carefully. While I like using the "absolute best" tool for the task (whatever "absolute best" means), I wouldn't necessarily use it without considering other factors such as:</p> <ul> <li>do we have sufficient skill and experience to implement successfully</li> <li>will we be able to find the necessary resources to maintain it</li> <li>do we already use the language/tech in our system</li> <li>does the increase in complexity to the overall system (e.g. integration issues, the impact on build automation) outweigh the benefits of using the "absolute best" language</li> <li>is there another language that we already use and have experience in that is usable in lieu of the "absolute best" language</li> </ul> <p>I worked a system with around a dozen engineers that used C++, Java, SQL, TCL, C, shell scripts, and just a touch of Perl. I was proud that we used the "best language" where they made sense, but, in one case, using the "best language" (TCL) was a mistake - <strong>not</strong> because it was TCL - but rather because we <strong>failed to observe the full costs-vs-benefits of the choice:*</strong></p> <ul> <li><p>we had only 1 engineer deeply familiar with TCL - the original engineer who refused to use anything but TCL for a particular target component - and then that engineer left the project</p></li> <li><p>this target component was the only part of the system to use TCL and it was small relative to the other components in the system</p></li> <li><p>the component could have been also implemented in another language we already used that we had plenty of experience in (C or C++) with some extra effort</p></li> <li><p>the component appeared deceptively simple, but in reality had subtle corner cases that bit us in production (not something we could have known then, but always something to consider as a possibility later)</p></li> <li><p>we had to implement special changes to the nightly build because the <em>TCL</em> compiler (yes, we <em>compiled</em> the TCL code into an executable) wouldn't work unless it could first throw its logo up on the screen - a screen which wasn't available during a cron-initiated automated nightly build. (We resorted to using <a href="http://www.google.com/search?q=xvfb" rel="nofollow noreferrer">xvfb</a> to satisfy it.)</p></li> <li><p>when bugs turned up, we had difficult time finding engineers who wanted to work on it</p></li> <li><p>when problems with this component cropped up only after sustained load in the field, we lacked the experience and deep understanding of the TCL execution engine to easily debug it in the field</p></li> <li><p>finally, the maintenance and sustainment team, which is a much smaller team with fewer resources than the main development team, had one more language that they needed training and experience in just to support this relatively small component</p></li> </ul> <p>Although there were a number of things we could have done to head-off some of the issues we hit down the road (e.g. put more emphasis on getting TCL experience earlier, running better tests to detect the issues earlier, etc), my point is that the overall cost-vs-benefit didn't justify using TCL to code that single component. <em>Again, it was <strong>not</strong> a mistake to use TCL because it was TCL (TCL is a fine language), but rather it was a mistake because we failed to give full consideration to the cost-vs-benefits</em>.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload