• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Software Mistakes and Tradeoffs: Choosing your tech stack

 
Ranch Hand
Posts: 49
Firefox Browser Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What are the biggest mistakes programmers make when choosing a tech stack for their application? Thanks.
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In my experience the main problem is jumping to a technology shopping excercise before fully understanding the problem.
 
Author
Posts: 13
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am trying to share my experience around that topic in the "Third-party libraries: Libraries you use become your code" and "Keeping up to date with trends vs. cost of maintenance of your code" chapters.
The first part is about owning things - understanding that everything you import to your software is effectively becoming your responsibility. If your software fails, and the 3rd party library causes that failure, your clients don't care if it is your code or not. So due diligence when picking 3rd party libraries (or not picking a library at all and re-implementing a small part that you need would be a solution for that).
The second problem that is covered in the "Keeping up to date with trends vs. cost of maintenance of your code" chapter focuses on the issue of jumping into "trendy" new technology. Doing so may be problematic for your application because the new framework may not be mature and may not fit your context.
 
Marshal
Posts: 80281
432
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That is rather like the eBay problem: if a seller despatches the goods promptly but uses a delivery company who take a long time, the buyer receives the purchase late. And sellers should know who delivers on time and who doesn't. In eBay's case, not sure, but I think you can't give negative feedback if the delivery company delays the purchase.
 
Campbell Ritchie
Marshal
Posts: 80281
432
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How much do you say about companies using older versions of programs, for example sticking with Java8, because they have been better tried and tested?
 
Frank Carver
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And following on from Campbell's question, what about the continual pressure to "upgrade" to a different library, framework, or even programming language?
 
Marshal
Posts: 5817
374
IntelliJ IDE Python TypeScript Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I had an interesting conversation with a friend today about a project he was managing. There was a desire within the team to use Kubernetes, and there was some debate about whether that was a good choice or not. The conclusion was that even though it might not have been a perfect fit in terms of technology for the presented problem, it was the technology the team were most familiar with when it came to supporting and resolving production issues. It was an interesting take, and certainly some validity in it, that the "right" technology choice should be considered not only for development, but for support and maintenance too.
 
Rancher
Posts: 379
22
Mac OS X Monad Clojure Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Frank Carver wrote:And following on from Campbell's question, what about the continual pressure to "upgrade" to a different library, framework, or even programming language?



I suspect our team is somewhat unusual but we run a regularly-scheduled job to check for outdated dependencies and we generally update everything as a matter of course (after carefully checking the release notes!). We have a few libraries that are "old" -- where there's a breaking change across versions and we haven't scheduled the time to adapt to that -- but in general, we keep everything on the latest versions as much as we can.

The upside to this is that library updates are generally "easy" because we're only updating a few at a time and they're nearly all patch-level changes. It also means we often avoid CVEs that get discovered in older versions of libraries.

Of course, every now and then, a patch-level update contains a breaking change -- I'm looking at you netty-socketio!
 
Every time you till, you lose 30% of your organic matter. But this tiny ad is durable:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic