Software Quality and the Danger of Professional Code Monkeys

“Software Engineer”, “Computer Programmer” or “Developer” – these terms seem to be used interchangeably these days right? I suppose it is a step up from “the IT guy” but to consider these as the same role is rather missing the point. For many years I have discussed the merits and challenges in trying to differentiate the terms. In recruiting I insist that we are looking for “Software Engineers” which in my mind means something quite specific but given the applicants I see does not necessarily mean the same across the board. In fact the most vociferous response I had to that moniker was from engineers in other disciplines. “That’s not engineering!” they said, “There is no certification, no accountability and no rigorous standards you adhere to”.

The sad thing is – I think they are right. If we, as software engineers (or professional developers if you prefer) wish to be taken seriously then we have to listen to these criticisms. Engineering requires standards, it requires life long learning and it requires true accountability for actions. Think about a civil engineering project – nobody stands for a complete failure of a building or a bridge – but software issues are both expected and largely ignored. If we expect to be taken seriously then we need to hold ourselves to similar standards. It is a sad reflection on the state of the software industry that “Have you turned it off and back on again?” is globally understood as the remedy to most issues. Yes computer systems are complicated and yes the number of variables at play can seem daunting but does anyone truly believe that we are dealing with more complicated systems than the real world? At least computers do precisely what they were programmed to do – if we can’t explain what happened then we’re probably not very good at our job.

In my mind this is at least partly due to the considerable effort put into “lowering the barrier to entry” within the software world. The idea is an important one but it has led to a generation of software that can literally be put together by copying lines from popular Q&A sites and pasting into a development environment. If the code runs and seems to work the we’re done. Well no, not really. Is it tested? Is is easy to use? Does it conform to the design criteria or specifications? What happens if a user enters unexpected information or commands? What if the internet goes down or there is a failure in some subsystem? (A rhetorical question of course, as we will turn it off, back on and try again.)

There is no wonder that software gets a bad reputation when you look at what we expect people to put up with. User experience is touted as a glorious new concept – but how can we defend the creation of software that made no sense to the uninitiated? Do automotive manufacturers expect people to read a user manual before stepping into a new car? Can washing machine or dish-washer designers expect folk to attend a training event at a local store? The very idea that people are scared to try new software or upgrade what they have indicates the fragility of the ecosystem that we have all been complicit in creating.

Whether it was an intentional move to improve the recruitment pipeline or if it was implied in the requirements of a young software company there is a new push for “fast tracking” a software engineering career. At a recent meeting of the ScotlandIS software engineering leaders forum we discussed this very topic and around the table nearly 80% of the attendees thought we should be able to take a graduate level computer programmer and accelerate them to a senior software engineer in 18 months to 2 years. Can this really be an expectation that people have? My experience has shown that, even with a world class academic institution or phenomenal technical organisation behind you, it’s more likely to take 5 to 10 years to attain a high level of discipline in this field. Even if the “hard skills” can be learned in a compressed time-frame it will still take a large amount of practice to understand how these concepts apply in different situations.

The only source of knowledge is experience.
– Albert Einstein

Like it or loathe it there are various movements aiming to improve the stability and professionalism of our beloved software ecosystem. Test Driven Development may be the marmite of the software development world (you either use it religiously or are adamant that your team can’t spare the time) but it understands that quality is an issue for software creation. If we are to be taken seriously by engineering organisations, professional bodies and the populace at large then we need to think hard about these standards. Perhaps the British Computer Society are on to something with their push to get chartered status for software professionals? Such a move may be an additional hurdle to professional status but that does not have to mean it’s any harder to get started in the industry. If we can successfully champion the importance of separating learning and exploration from the creation of consumer and business products then perhaps we can actually raise the bar for software quality and earn our engineering status.

(Image from Code Monkey animation – visuals by idleambition, original song by Jonathan Coulton)

That’s a Fyne deck of cards

I wanted to start looking at other uses for vector graphics in an application as I develop Fyne further. Then it came to me, a card game!

I managed to find a great public domain set of graphics and whipped up a card back from the fyne logo. From there laying out a simple solitaire board was a piece of cake by just implementing fyne.Layout :).

I’ll upload this to the examples repository once it is a little more complete – I didn’t think that a gloried screenshot justified the code push. But for those who want that screenshot here it is 🙂

More to come soon I hope!

Mahler 8 closes another Festival

Yesterday saw the final Usher Hall concert of the 2018 Edinburgh International Festival. And what a night! Daniel Harding and the Swedish Radio Symphony Orchestra did a fantastic job showing the somewhat softer side of Mahler’s “Symphony of a Thousand”. On stage with them were the Edinburgh Festival Chorus (who invited me to join them), the National Girls Choir (part of NYCoS) and 8 fantastic soloists.

The performance offered a variety of subtle times and immense power that earned audible gasps from the audience. It’s a stellar piece and it was great to be part of it. Quite a send off for chorus’s fearless leader, Christopher Bell (of NYCoS fame and now making a storm in the USA). I look forward to the chance to sing in one of his choirs again at some point in the future.

A few folk were good enough to give us 5 star reviews as well!

⭐️⭐️⭐️⭐️⭐️ Ken Walton

https://www.scotsman.com/lifestyle/culture/edinburgh-festivals/music-review-mahler-s-eighth-symphony-1-4790382

Photo copyright The Scotsman

Back home at CodeBase

Although it feels like only yesterday I realised this week that I moved out of CodeBase pretty much a year ago. In that time I have missed the community spirit and light-hearted competitiveness of the various individuals and teams working to build the next big thing. Whilst I have enjoyed my time working on various coding contracts and technical leadership consultancy placements (most recently through Intuitus) it seemed time to push myself to start a new venture.

And so here I am again! The kind folks at CodeBase managed to find me a desk in their co-working space which plays host to many companies, most of which I had never met before. While I guess I was never too far away (I tried to keep the CTO group running during the last year) it is great to officially be back in the building, bootstrapping and learning alongside some of Edinburgh’s brightest young business sparks.

If you’d like to know more about my plans then you can watch this space, or that of the brand that I’m developing named FossFish. The plan is to do something big in the open-source-meets-business arena which I’m excited to share more about soon. In the meantime we are working on some enabling technologies including Fyne and others which will be announced later.

If you’re in the neighbourhood please stop by and say hi 🙂

The First 10 Days of Fyne

Wow it’s been a busy few days getting the Fyne project up and running. It’s been well received by a large number of people already – gaining more people on our chat channel in 1 week than the Edi IDE project gained in almost 2 years!

To mark the occasion of 10 days I added a blog post (and blog page 🙂 ) to the website summarising what we’ve done so far. If you just want to check out the details then check out the github project.

Go is proving to be a powerful and quick to learn language – check it out!

A different direction for a brighter future

What follows is an email I sent to the Enligthenment Developer list today. For some time I have wondered if the project has lost it’s way and I finally decided it’s time to make a move – and announce my new project at http://fyne.io! I know there are others who are thinking about what the future might hold in desktop software – if you want to try something new please get in touch!

I’ve been following the Enlightenment project for 15 years having got involved originally due to the catchy graphics, innovative approach and friendly community. We’ve had up times and down times as some may remember but right now I have serious concerns about the future of this project.

When I joined the Enlightenment team it felt like we were building something shiny and new for those that wanted a slick, beautiful alternative desktop. After many years of development we got E17 and the EFL, but who was EFL for? It enables E but why are we building it (for whom)? Over time this question has become harder to answer and with commercial support came additional confusion as to its purpose. Take Elementary for example. It is documented as being light and minimal, but it isn’t. We encourage developers to build desktop apps despite it not being built for purpose and we allow widget contributions from people who don’t even test with the standard theme.

In addition are the technical issues with our (EFL) codebase. It has evolved organically since the beginning and we have had various namespace changes, splitting and re-combining that brings with it a significant legacy. The Eo/Interfaces project was a chance to leave that behind and build things “the right way” but unfortunately it’s implementation is being heavily shaped by legacy choices or restrictions that are bleeding out through the new API as complexity or confusion. The type of change that we are attempting cannot be completed effectively without up front planning, guiding vision and regular releases to our target audience.

And finally I have observed over the last few years our community becoming less friendly – at times even hostile – towards developers both new and established. When I started Edi to help get new developers on board our mailing list and IRC channel welcomed inquisitive, questioning minds but now I often see contrary thought being beaten back. I don’t know the cause of this change but I do see it damaging our chances of success.

Unfortunately I don’t think these problems can be fixed within the current project and community. Therefore I have decided to work on something new and separate so that I can avoid these shortcomings.

This new project aims to provide a great API for application developers to quickly create beautiful, usable, lightweight applications for desktop and mobile. Driven by design and usability principles it is a chance to break from current desktop app drudgery to create something joyous akin to material design and iOS’s interface simplicity.

Ideally it will be built on top of EFL, leveraging the great work that exists here but abstracting it away from the user so that internal changes and object lifecycle never bother API users. The development environment will be polished such that new developers can easily get up and running using the same tools as the development team. It will be built using modern tooling and platforms that reduce the barrier to entry and allow any potential developers or collaborators to see what we are working towards, how we are doing and how they can get involved.

[snip]

If anyone reading these posts is interested in getting involved then please check out our current status at the fyne repo wiki. I am excited about what can be created if we are not stuck with a significant legacy of old code and negative thinking :).

Photo by Franck Veschi on Unsplash

The wrong company can seriously damage your health

One of my favourite topics is startups – discussions about the benefits of young companies and how innovative workspaces can be a boon to productivity and healthy work life balance. It would be remiss of me, however, to imply that it is always great. There is a lot of hard work involved of course but it is also possible to have negative workplaces amongst all this innovation.

This post is about the importance of identifying a bad workplace, poor cultural fit and how it can impact negatively on your health – mental and physical. And why it is important to identify early and do something about it.

What is bad?

Well beyond the obvious understanding of a bad workplace (abusive staff, tyrannical boss, inappropriate language, sexism etc) there are plenty of things that can lead to a negative environment:

  • Blame culture – when something goes wrong does the team work together to solve the issue or does it focus on who caused the problem (publicly or not) and require them to fix it?
  • Unclear objectives – does everyone on the team know what is expected of them or why they are working on their task? Omission of a clear plan can lead to a drop in morale.
  • Lack of communication – sharing plans, collaborating in decision making and listening to your teams will help everyone to feel supported and understand their role.
  • Dishonesty – it can be assumed that for the most part people you work with are honest, some companies even find the need to list it in their values. But what about the difficult truths or glossing over things that should be addressed? Openness requires real honesty and that can be difficult.
  • Long hours – whilst probably required at some point in most jobs is this used sparingly? Is the decision to put in extra time one of the group or is it mandated?
  • Values failure – in a company that is clear about its values does everyone live by them? Are there times when they are pushed to one side? During times of pressure you often see what a team is really made of.

Of course there are many more potential reasons for a workplace to affect you negatively and they may not be obvious. Some times the thing that brings a company or team down is not obvious at all…

Hiding in plain sight

Sometimes the cause of a bad environment might be hard to spot. It could be that despite best intentions something is not as intended.

In a values based organisation how are these communicated? Does everyone know the company values by the way that people talk, work and collaborate – or is it something that everyone is reminded of in publications, marketing or (even worse) is it painted on the walls? If everyone truly valued the same things then such constant reminders should not be required.

If teams work well during normal operation what happens if an item of work does not go to plan? If an engineering team’s release is being held up by an item of work what is the typical behaviour? The team working together to get it back on track – or individuals being left to figure it out for themselves?

Individual vs company wide

It may even be that everyone is happy but you just don’t fit in. Perhaps the values don’t align or maybe your sense of humour is incompatible. Do you feel comfortable with your workmates and business leaders? A long interview process should allow for a high chance that the match of a candidate to the team is solid but no process is perfect. It may be that you just don’t feel a good fit. If you get to the end of any probation period (usually 3 – 6 months within the company) and you are not happy then this is probably a good sign that the company is not for you.

Making your exit

If you wake up on Monday morning (or even worse, Sunday night) dreading going back to work for the week that might be a sign that it’s not working out. If you think your lunch break should be longer, if you find yourself having no discussions in the office or if you find that chats always turn into arguments or leave you annoyed then it’s probably time.

As soon as you realise that the fit is not there it’s time to start planning your exit. Staying longer may seem like the noble thing to do but you will only get more annoyed at the job, likely bring down your co-workers and possibly damage your health as well. Most people working in startups or technology companies have options, there is huge demand for your skill set – look at alternative companies and maybe go on a few interviews. Also consider sharing your concerns with your boss – if they understand and agree that it’s not working out then they may even help you find the right role elsewhere.

Believe me you don’t want to realise too late that you should have made the move and that it’s deteriorated your health. It’s no fun having to take 6 months out of the fast moving tech world because you don’t have the strength or energy to greet the world. It’s also no fun being in the doctor/nurse’s office twice a week getting vitamin boosters to put your blood levels back in balance! Life is too important and the right balance should mean keeping good health!

Happy New Year to all my readers and may you have an exciting, healthy 2018 :).