Maintainable software requires these three things

For software to be considered maintainable, it requires 3 things:

1. For there to be (documented) knowledge of everything the software does (and doesn't/shouldn't) do.
2. For there to be a simple way of verifying the software behaves as intended.
3. For it to be written in a way that makes it clear to a person looking at the code what it does, so it avoids any unintentional side effects when changed.

Point 1 doesn't require a specific format or way of recording this information. Use what works best for you, the team, the company, and the project.

Point 2 can involve a combination of tools and may require some manual effort.

Point 3 is dependent upon the skills and existing knowledge of the person making a change. It's okay to require a minimum level of knowledge of the language, framework, codebase, etc. The goal, as far as possible and in combination with other requirements, is to have unambiguous code that is clear about what it does. (With documentation--and possibly comments--explaining why, where necessary.)

"As an architect, part of my job is to improve the way we do things"

I was recently listening to a podcast and was struck when the interviewee (a "senior software architect" at a large company) confidently stated that:

"As an architect, part of my job is to improve the way we do things."

Two things jumped out at me about this statement and the way it was made:

1. It implied that other people at the company don't look for ways to improve things.
2. It implied that other people at the company aren't allowed to suggest improvements.

I find this concerning.

I consider it everybody's job to always be on the lookout for ways to improve things.

Not that people should be spending a lot of dedicated time focusing on looking at and evaluating alternatives, but that everyone should have an awareness of challenges and opportunities for improvement and should share these when appropriate.

Many years ago, after the weekly developer team meeting at a company I was about to leave, someone else on the team asked why I had suggested a change to a process in that I'd be leaving in a few days.

I made the suggestion because it would be better for everyone working there. Even if that only included me for a few more days.

That other person was happy to be told what to do and then do it. No questions asked.

I don't want to work like that (and probably wouldn't last that long in such an environment.)

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.

Windows Phone - I remember you well - Now what?

I recently found myself with some spare time (because of a lack of a broadband connection and living remotely), and so I did some tidying up of things I'd been meaning to get around to.

I discovered a "box of broken dreams" - a box full of old phones, tablets, and assorted electronic devices - that have long since passed their usefulness (even as test devices).

In that box were 21 different old Windows Phone devices. They ranged from one of the first test devices in the country to one of the last models released and a wide variety of things in between.

Here is a video where I look at them and reminisce.

But after that trip down memory lane, what now?

What do I do with all these old devices?

What should I do with the promotional devices that are still in their boxes?

Bonus question: Any idea how I get images off a device running Windows Phone 7.5 and that won't connect to Zune over USB? (And no, there's no file system, and while it can connect to the internet, there's no way to upload the images via a website.)