Last time I touched upon the subject I wrote about downright avoiding additional code - because everything has a cost. There, however, is one genuine exception: one should aggressively automate the deployment pipeline from the very first moment regardless of the type of the project. Even if it is just a throwaway script, put in mechanisms that automate environment setup and possible installation and configuration. A year later, when something breaks and it needs to be tweaked you have your automation to lean on to as a form of documentation (careful commenting is also recommended).

I’ll show a specific example I’ve used in a project where a cross-compilation environment on a server is used to build up a device image and then I flash the device image locally on my dev computer:

.phony: clean

all: backup clean makeatserver cpfromserver cptodevice

makeatserver:
	ssh -t server 'cd /path/at/server/repository && git submodule update && git pull --rebase && make'

cpfromserver:
	scp server:/path/at/server/build/bin/*.bin /localpath/devicebins && scp server:/path/at/server/build/*.dnl /localpath/devicebins && scp server:/path/at/server/build/*.bin /localpath/devicebins

cptodevice:
	customcommand flash device

clean:
	rm -rf *.bin *.dmp *.hex *.list *.map *.elf *.dnl

backup:
	mkdir -p previous && [ -f flashimage ] && cp *.bin previous/ || echo "no files to backup"

This is part VI of my series of What do you Believe in as a SW Developer? // Timo Koola

Today, in “What do I believe in as a developer” I will shortly lay ground for next few days with two conflicting forces or principles that pull apart developers.

Firstly, never fix something that isn’t broken. Usually going with something you know and trust is much better than trying to outpace everyone else with the technology du jour.

Except, sometimes you need to be early for several reasons. Some tech is just so much better than what came before that the world will quickly follow. For instance, hosting your own web server on premises definitely never was broken, it is very much a known known but one literally can make orders of magnitude saving in time and money using modern tech.

Following few days I will go through technologies, methods, and techniques that I think are affected by these two conflicting forces and will try to explain why I make selections the way I do.

This is part IV of my series of What do you Believe in as a SW Developer? // Timo Koola

Jumping around in my list of SW related foundational beliefs I picked up today: Embrace the Platform

As I said yesterday in my WDIBI II: Choose Speed // Timo Koola post, I firmly believe in speed over developer experience. One other area where I think developer should prioritise user experience over developer experience is when selecting tools to address users in different platforms. I firmly believe that developer that actually thinks users first (as everyone claims to do) never picks a cross-platform framework to develop their application.

I consider there to be three major platforms:

• Web (both websites and web applications)
• iOS
• Android

I think if you are going support users on one or more of these platforms one should do a native solution for each. For web, if possible, stick to easy and simple yet immensely powerful tools that plain old HTML and CSS give you. I could go on and on about web but expletive deleted Website explains it very thoroughly. Sometimes one needs to do something more complicated and resorting to something like React is perfectly fine. I just think one needs to be very careful about performance and accessibility.

As for Android and iOS, if you are serious about your users go with native solutions for respective platform - build with native idioms and frameworks and you’ll save a lot of cross-platform headaches that are not going to give anything to your users anyway.

Specifically I don’t recommend (if asked) using React Native, building up a PWA (I might write about their specific problems some day), or Flutter. Stick to platform tools, your user likes their iPhone way more than they do care about your brand (unless you happen to be WeChat) Apple’s China Problem – Stratechery by Ben Thompson

How about legacy platforms like Mac or Windows? I’d say it depends - are you really going to address the people on this platform? Go native. Do you just want to cover as much area as possible? Consider using web to address these platforms.

Just one quick parting note - this of course applies only to software directly accessing consumer needs. Calculation for Enterprise software might be different and for some enterprise internal tooling very, very different. I’d still say even within “enterprise” go native, if your use case depends on user experience. In other areas: do the best thing for the team.

This is part I of my series of What do you Believe in as a SW Developer? // Timo Koola

Yesterday I wrote about fun WDIBI I: Programming should be fun // Timo Koola. Today I am going to jump to other end of my list of things that I believe in as a programmer - my belief in speed:

Choose Speed

I vehemently believe software always should be as fast as it can ever be (and often simultaneously as small as it can be). I don’t think one can ”prematurely optimize”. Far more often modern software errs on the side of ”premature flexibility” or ”developer experience” without a clear user benefit. Speed, however is universally valued by real users from web sites to native apps to embedded software.

This is part I of my series of What do you Believe in as a SW Developer? // Timo Koola

I have had a What do you Believe in as a SW Developer? // Timo Koola blog post brewing in me for months. I have Foam // Timo Koola notes of it ready, parts of it thought out but it seems too menacing task to write at once. So, I need a change of plan. I will write items on my foam notes one by one this month (no NaNoWriMo for me this year either)

Lately I’ve pondered the following question: what are the things that I believe in as a software developer? I mean notions, ideas, concepts, or even principles that you lean on when making decisions and trade-offs. This time I am concentrating on professional beliefs even if I think moral and political beliefs are important also in a professional context.

I think these kind of principles must be such that one can have reasonable arguments about perhaps with solid data. For instance I don’t count “I believe in quality software”. Nobody would be on the other side of that argument and it boils down to have no meaning. A good principle would be something like: “I think monoliths are better than micro-services”. One can sit on either side of that argument and good software is written on both sides of that divide and yet most people have an opinion about which one to choose if the choice is available.

Ideas that one believes in don’t need to be big, abstract thoughts. One can have an opinion on tabs vs. spaces or perhaps that one should always, always use semicolons in Javascript. You can write successful software whatever your opinion is on those matters but usually you do have an opinion.

I think I have an initial list in mind but it needs some fine-tuning as the abstraction level on my list varies from quite small to pretty abstract. What is on your list of software design principles?