Progress360 2022: day two keynote - lies developers tell themselves
The Computer Weekly DeveloperNetwork team is on the road again and this time it’s Boston, USA for Progress Software’s Progress360 developer event, staged from September 11-14, 2022. This event combines DevReach and ChefConf.
Keynote day #2 was presented by Billy Hollis, regional director at Microsoft under the title: ‘Lies Developers Tell Themselves’.
Hollis previewed his session with the following notes…
All humans deceive themselves sometimes and developers are no exception. From ‘I can get this done in a week’ to ‘my job is to write code’, developers often convince themselves of things that are only partially true — or are even outright ridiculous.
These seductive-but-false notions are factors in everything from poor software quality to unnecessary stress on developers and other team members. In this session, developer/designer/architect Billy Hollis will discuss his top ten uncomfortable truths about software development, adding some humor to make them easier to hear.
During the presentation itself, Hollis detailed some of the major developer pitfalls that he thinks exist:
1 – I can get it done
Developers who think that they can estimate how long a job takes should step back and give people what are typically wider time windows. Like it or not, estimation is a skill and is a part of software application development.
2 – My job is code
“Many developers have a substance abuse problem – and that substance is code,” said Hollis. In a point designed to illustrate how far developers often think that their main job is to deliver code – spoiler alert, it’s not – their job is really to create great value software that works for users, so it’s not just a question of chugging out lines of code. Hollis says that many times, developers often start to code a solution to a user problem [during a requirements meeting perhaps] before they have even listened to the full scope of the user request.
3 – Juice up a GUI
Simply ‘juicing up a user interface’ (think about Windows 8) is not enough to draw users into an application or service – there needs to be a more architectural approach at a lower level first.
4 – Architecture anomaly
Hollis suggests that there are a lot of people with the word architecture in their job title, but that very few of these people really do architecture. Simply researching what APIs you’re going to need is not architecture.
5 – Show the users
So many developers think that they have to build something to show the users. Learning what users really need is a skill – and the challenge here is that users can’t design for you (the developers), but they do understand their jobs, so developers need to learn how to talk to users and grasp an understanding of their jobs.
6 – Listening is a skill
Suggesting that the period of active listening (that most people are capable of when interacting with each other) is, typically, as short as 30 seconds – and this is a real setback for developers who really need to be playing a functional part of teams that can interact with users/customers and be able to create great software.
7 – I love process X
A nice end point covering the wider management and orchestration of software application development at the highest level of project status, Hollis suggested that one of the great lies that developers tell themselves is that they ‘love [their] process X’ and think that everyone should use it. Whatever flavour of Agile a particular developer likes is great, but programmers should realise that ‘one true way thinking’ does not necessarily exist and that each team will really need to find its own place in space and time when it comes to software process.
Certainly one of the more entertaining sessions delivered at any technology show in recent times, Hollis would be an appealing second-sitting if he appears at other conferences i.e. one imagines that (like his subject matter) he delivers a slightly different final product tailored to suit each individual audience he speaks to.
One final piece of Hollis logic – he says he doesn’t even use adjustable baseball caps, he only wears sized baseball caps, they just ‘work better’ for everyday use… what more insight could any developer possible need than that?
Hollis started coding in 1973, so he’s seen the highs & lows and ups & downs of programming.