Why UI code matters

As a simplification, there are three types of software:

1. Client/frontend
2. Headless/backend
3. Embedded

(Sure, there is some overlap and some things straddle these loose definitions.)

What separates client/frontend software from the others is that it has a graphical user interface (GUI).

I'm a big fan of GUIs.
I like that they make software easier to use because I can see things and don't have to remember as many options, commands, or a set of seemingly magic words to get the software to do what I want.

For many, many people, GUIs make software possible, usable, and desirable.

However, for many developers, creating GUIs can be a source of frustration.

Regardless of whether using markup to describe the structure of the code or an imperative language that describes how to create it, GUI code can easily become verbose and hard to maintain.

If code is hard to maintain it becomes slower and therefore more expensive to modify without unintended consequences and negative side effects.

If spending extra time modifying hard to change code that means less time for doing other work. Such as fixing bugs or adding new features.

There are also the negative emotions and blows to motivation developers feel about having to work with hard to maintain code.

The GUI is also important as it's the part of the application that people (users) see and interact with. It's what many people will know as the face of the application that they may spend hours looking at each day. They may spend more time looking at it than other people or the faces of their loved ones. For something that gets that much time and attention from the people using the software, doesn't it deserve adequate consideration from a development perspective too?

It can be easy to dismiss the GUI as less important than other parts of a code base, but doing so is a mistake.

If it's a "proper" programming language is irrelevant

I changed the way I think about programming when I realised that compiled software is predominantly made of three things:

1. Binary assets (images, fonts, etc.)
2. Text files written (and/or readable) by people
3. Items generated by the above.

It's the second group that's most interesting.

Regardless of whether those text files are scripts, "code" to be compiled, mark-up, or pretty much anything else: if people are going to read (and/or write) it, isn't it beneficial that those files:

• are easy to read
• are easy to write
• are consistently formatted
• use meaningful words (names) to aid comprehension 
• are unambiguous 
• avoid duplication 
• are succinct (so as to avoid unnecessary verbosity)
• highlight issues/mistakes (or make them easy to spot)
• have good/appropriate tooling to aid in working with them

When this isn't true, those files are harder to maintain. This makes making changes lower and, therefore more expensive.

99.985% of coding is maintenance*

Maintaining code means changing it.

Those changes could be alterations to what's already there or in addition to what exists.

This isn't only true once a version has been released or shipped.

This is also true during initial development. 

Once there is other code, this needs to be read and understood, and additions/changes made in light of what already exists. 

Whether there is one existing line of code or one million; if what exists is hard to understand and reason about, future alterations to the code can be hard to integrate and risk unintended consequences. Both of which take more time/money. 

Maybe that's not a problem for you, but every developer I've ever met has more things they need to do. More bugs to fix, more features to add, or new products to create. Having more maintainable code means they get to more of those things; and faster!

Optimize for maintenance (ease of reading/comprehension) to save time/money in the short, medium, and long terms.

* Not a fact but an educated approximation.

"This is just demo code" is not an excuse

Many, many times, I've seen and heard people show code for the purpose of demonstrating something.

To allow them to focus on a specific aspect they may do some things in a sub-optimal way or a way that makes future maintenance of that code harder.

Sadly, it's common for such demonstrations to be accompanied by the disclaimer that "this is just demo code and you shouldn't write code like this in real projects." 

Technically, such disclaimers are good, but they're worthless if there is no separate example of what good looks like. (Ideally, the person giving the demonstration will point to such examples.)

If all the code people ever see is "demo quality" and not what "should" go in a robust, production-quality code base, that's all they'll ever write.

This also applies to overall maintainability.

If parts of a codebase are over-simplified/neglected/mistreated/obscured to give prominence to the particular aspect being demonstrated, it can be easy for people to think that the maintainability of ALL code isn't important, and so they start writing code like that too.

Please don't give such demos.
And, please, call me out if you ever see me doing this.

Speaking at conferences and being careful about what I wish for

Today, I was privileged to get to speak at the first MAUI Day in London. (I expect to write more about the conference overall and the things I showed--some for the first time anywhere--in the coming days.)

One of the aims of the talk was to get people thinking about something in a new way. 

Based on conversations with many of the people I spoke to after my talk, I was successful. 

However, what I didn't realize is that "you've really got me thinking" is a bit of a conversation stopper.

I need to let people have time to think.
I helped people recognize that something they thought to be an unchanged absolute doesn't have to be that way.
The status quo isn't the only option, and there are simple and not-so-simple ways of making significant change for the better.

For people who have been doing something for many years, to suddenly be shown and accept something new can be a lot to take in.

I wanted people to appreciate the situation so we could start having conversations about improving things.

I'm ready to have those conversations now, but others need more time to process their thoughts.

It would be nice if there was another conference next week where we could continue the conversation once people have had that mental processing time. Sadly, that's not the way attending conferences works (especially when so many attendees had travelled a long way to be there).  It's also rare, in my experience, for a talk to potentially change people's ideas on such a level. 

Still, overall, it's definitely a positive situation. 

And I'm looking forward to some of those future conversations.