10 ms·
> Only learn something new when forced This could be devastating, much more in little/medium company. I know of successful companies (I mean company with succ
by gabrielblack 7y ago
> Only learn something new when forced
This could be devastating, much more in little/medium company. I know of successful companies (I mean company with successful products ) with a C/C++ stack they considered "good enough" so they didn't change anything: the C++ standards, architecture, structures. Often that line of conduct was supported by a management looking any change or improvement as a cost. The result is always the same: a day they wake-up realizing that the "product" is a pile of crappy legacy code. I know some cases. One of those company was bought by a bigger company that asked to modify the stack to modern standards with disastrous results because the programmers wasn't skilled to port the code base to modern standards/architectures. In another case, the owners sold the entire division to another company, interested to the clients more than to the product and, after checking the status of the code base, the buyers hired a group of consultants that rewrote all in Java, with results that you can imagine.
- ensiferum 7y agoJust because something is old or uses old framework or old standard doesn't make it crap. Crappy code is crap, but it age doesn't make it crap. Code doesn't rust or detoriarate by itself. Example if you write good code now using C++14. If it's good code now it will continue to be good code 20 years later. There's no property that adds bugs or "crappiness" to the code as the years go past. The invention of a new "c++40" standard doesn't obsolete old code or turn it "crap".
- daemin 7y agoThe best thing about seeing the codebase for a long lived product is seeing the layers of when something was written by the types of patterns found in the code.
- gabrielblack 7y agoThe age make it "crap", but not in the way you think. I can speak about C++. C++ code wrote in the older standard, let say C++ pre-11, who are 20 or more years old make it difficult to maintain because new generation of programmers are not generally interested to legacy code or in learning old c++ standards and skilled programmers don't want be relegated to be eternally maintainer of old projects. For this reason projects die by asphyxia. We have that good code base in Cobol, ok, but the point is: who cares ? Who is important when you need new programmers. Besides, a part considerations on the language, the architecture is important we live in a world of microservices and old code not updated to modern paradigms could became "crap", even if if the most elegant code.