Published by Marco on 15. Aug 2014 08:29:47
------------------------------------------------------------------------

Encodo has never been about maintaining or establishing a monoculture in either
operating system, programming language or IDE. Pragmatism drives our technology
and environment choices. [1]

[Choosing technology]

Each project we work on has different requirements and we choose the tools and
technologies that fit best. A good fit involves considering:

  * What exists in the project already?
  * How much work needs to be done?
  * What future directions could the project take?
  * How maintainable is the solution/are the technologies?
  * How appropriate are various technologies?
  * What do our developers know how to do best?
  * What do the developers who will maintain the project know best? What are
    they capable of?
  * Is there framework code available that would help?

[History: Delphi and Java]

When we started out in 2005, we'd also spent years writing frameworks and highly
generic software. This kind of software is not really a product per se, but more
of a highly configurable programmable "engine", in which other programmers would
write their actual end-user applications.

A properly trained team can turn around products very quickly using this kind of
approach. It is not without its issues, though: maintaining a framework involves
a lot of work, especially producing documentation, examples and providing
support. While this is very interesting work, it can be hard to make lucrative,
so we decided to move away from this business and focus on creating individual
products.

Still, we stuck to the programming environment and platform that we knew best
[2] (and that our customers were requesting): we developed software mostly in
Delphi for projects that we already had. [3] For new products, we chose Java.

Why did we choose Java as our "next" language? Simply because Java satisfied a
lot of the requirements outlined above. We were moving into web development and
found Delphi's offerings lacking, both in the IDE as well as the library
support. So we moved on to using Eclipse with Jetty. We evaluated several common
Java development libraries and settled on Hibernate for our ORM and Tapestry for
our web framework (necessitating HiveMind as our IOC).

[History: .NET]

A few years later, we were faced with the stark reality that developing web
applications on Java (at the time) was fraught with issues, the worst of which
was extremely slow development-turnaround times. We found ourselves incapable of
properly estimating how long it would take to develop a project. We accept that
this may have been our fault, of course, but the reality was that (1 )we were
having trouble making money programming Java and (2) we weren't having any fun
anymore.

We'd landed a big project that would be deployed on both the web and Windows
desktops, with an emphasis on the Windows desktop clients. At this point, we
needed to reŽvaluate: such a large project required a development language,
runtime and IDE strong on the Windows Desktop. It also, in our view,
necessitated a return to highly generic programming, which we'd moved away from
for a while.

Our evaluation at the time included Groovy/Grails/Gtk, Python/Django/Gtk,
Java/Swing/SWT/Web framekworks, etc. We made the decision based on various
factors (tools, platform suitability, etc.) and moved to .NET/C# for developing
our metadata framework Quino, upon which we would build the array of
applications required for this big project.

[Today (2014)]

We're still developing a lot of software in C# and .NET but also have a project
that's built entirely in Python. [4] We're not at all opposed to a suggestion by
a customer that we add services to their Java framework on another project,
because that's what's best there.

We've had some projects that run on a Linux/Mono stack on dedicated hardware.
For that project, we made a build-server infrastructure in Linux that created
the embedded OS with our software in it.

Most of our infrastructure runs on Linux with a few Windows VMs where needed to
host or test software. We use PostgreSql wherever we can and MS-SQL when the
customer requires it. [5]

We've been doing a lot of web projects lately, which means the usual client-side
mix of technology (JS/CSS/HTML). We use jQuery, but prefer Knockout for
data-binding. We've evaluated the big libraries -- Angular, Backbone, Ember --
and found them to be too all-encompassing for our needs.

We've evaluated both Dart and TypeScript to see if those are useful yet. We've
since moved to TypeScript for all of our projects but are still keeping an eye
on Dart.

We use LESS instead of pure CSS. We've used SCSS as well, but prefer LESS. We're
using Bootstrap in some projects but find it to be too restrictive, especially
where we can use Flexbox for layout on modern browsers.

And, with the web comes development, support and testing for iOS and other
mobile devices, which to some degree necessitates a move from pure .NET/C# and
toward a mix.

We constantly reŽvaluate our tools, as well. We use JetBrains WebStorm instead
of Visual Studio for some tasks: it's better at finding problems in JavaScript
and LESS. We also use PhpStorm for our corporate web site, including these
blogs. We used the Java-based Jenkins build server for years but moved to
JetBrains TeamCity because it better supports the kind of projects we need to
build.

[Conclusion]

The description above is meant to illustrate flexibility, not chaos. We are
quite structured and, again, pragmatic in our approach.

Given the choice, we tend to work in .NET because we have the most experience
and supporting frameworks and software for it. We use .NET/C# because it's the
best choice for many of the projects we have, but we are most definitely not a
pure Microsoft development shop.

I hope that gives you a better idea of Encodo's attitude toward software
development.

--------------------------------------------------------------------------------


[1] If it's not obvious, we employ the good kind of pragmatism, where we choose
    the best tool for the job and the situation, not the bad kind, founded in
    laziness and unwillingness to think about complex problems. Just so we're
    clear.


[1] Remo had spent most of his career working with Borland's offerings, whereas
    I had started our with Borland's Object Pascal before moving on to the first
    version of Delphi, then Microsoft C++ and MFC for many years. After that
    came the original version of ASP.NET with the "old" VB/VBScript and,
    finally, back to Delphi at Opus Software.


[1] We were actually developing on Windows using Delphi and then deploying on
    Linux, doing final debugging with Borland's Linux IDE, Kylix. The software
    to be deployed on Linux was headless, which made it much easier to write
    cross-platform code.


[1] For better or worse; we inherited a Windows GUI in Python, which is not very
    practical, but I digress


[1] Which is almost always, unfortunately.