<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Forem: Alex</title>
    <description>The latest articles on Forem by Alex (@cognophile).</description>
    <link>https://forem.com/cognophile</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F156821%2F9c021442-93e1-41fb-afd7-f00fa849927d.PNG</url>
      <title>Forem: Alex</title>
      <link>https://forem.com/cognophile</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://forem.com/feed/cognophile"/>
    <language>en</language>
    <item>
      <title>Choose a technology stack, choose your fate...</title>
      <dc:creator>Alex</dc:creator>
      <pubDate>Thu, 27 Feb 2020 01:28:32 +0000</pubDate>
      <link>https://forem.com/cognophile/choose-a-technology-choose-your-fate-307</link>
      <guid>https://forem.com/cognophile/choose-a-technology-choose-your-fate-307</guid>
      <description>&lt;p&gt;At times, starting a fresh software project can be pretty daunting. There's nothing more exciting than a blank canvas, and yet, there's a lot to plan and consider which can make it difficult to know whether the choices we make are the right ones. Resources, design and architecture, tooling, releases, documentation - we all know the list goes on and it all needs to be considered. And though it's true that we should strive to be technology independent in our approach, ultimately, it doesn't always work out that way in practice. &lt;/p&gt;

&lt;p&gt;So perhaps one of the most impactful factors in the long-term is the technological choices we make. We often have a vision in mind for the end product which might include a backlog of features and the platforms it should be available on, but failing to consider or evaluate our options when making these early technological choices that we ultimately rely upon, can easily morph into a headache of technical debt or limitations down the road. &lt;/p&gt;

&lt;p&gt;In short, many of the factors which I've witnessed often sound a little like &lt;em&gt;"we use it because we know it"&lt;/em&gt;, &lt;em&gt;"we've always supported XYZ so why try and support ABC, too?"&lt;/em&gt;, &lt;em&gt;"this is the new hotness - let's use it for something"&lt;/em&gt;, &lt;em&gt;"let's branch out a bit and learn and use ABC"&lt;/em&gt;, &lt;em&gt;"XYZ has had solid and consistent development and maintenance so it seems a safe bet"&lt;/em&gt;.&lt;/p&gt;

&lt;p&gt;For example, you can find plenty of information about options for starting a new cross-platform desktop GUI project - a wealth of tech-stack options exist from the usual suspects (Electron, Element, Qt, &lt;em&gt;X&lt;/em&gt; + GTK*, Java Swing, JavaFX, .NETCore + AvaloniaUI, etc.), all the way to the more elaborate solutions like locally hosted web applications, but the question remains: what criteria and process do you find works well to whittle them down when you don't have strong experience of them all? &lt;/p&gt;

&lt;p&gt;I often find a few simple spike projects in the main options and a browse of some documentation and community discussion will help, but time isn't always on our side to allow that kind of experimentation. For me, it's a key factor that there be well-written and comprehensive the documentation, and a thriving community for help and discussion!&lt;/p&gt;

&lt;p&gt;I'd love to hear about what processes and constraints you find useful when deciding which competing technology stack to use to kick-start the product into life. How do you, your team, or organisations go about weighting technology choices and making a decision? Are there any resources you've found particularly enlightening in these situations? &lt;/p&gt;

</description>
      <category>discuss</category>
      <category>help</category>
    </item>
  </channel>
</rss>
