Programming is Easy; Developers are lazy, (and a bit elitist).

Programming is easy, developers are lazy (and a bit elitist). Software development and computing has been my life and my career for as long as I care to remember - so I feel I'm entitled to my opinions about developers and the state of programming today - but do please bear with me, because this isn't a bad thing at all.

However, we are at a crisis point across the IT industry at the moment, and we need to make some changes to mitigate a global slow-down in digital transformation, innovation and technological progress.

I'd like to just start with a bit of history - reflecting back on the state of programming "back in the day". Going back to the 1950s when computers first started to have the ability to store and execute programs from memory, machines like the US Government's UNIVAC 1101 were programmed with punched cards. An air-defence program was written, using 62,500 individual cards - equivalent to 5MB of data.

The task of programming was laborious and error prone. One of the challenges was ensuring cards did not get misplaced, dropped or stacked in the wrong order - debugging this and getting program back in the correct order could take days or weeks, especially on the punch cards which had no human readable text printed on them. The capabilities of the computers were limited and simple - they were often designed with a specific set of tasks in mind. The actual computation process migh take hours or days to complete. I was fortunate enough to have avoided ever having to use punch cards, but in my late teens Universities still did use and teach programming in COBOL, Fortran or Assembler, using punch-cards as the primary input mechanism.

Punched card programming continued well into the 1970s, but became replaced as input and storage devices evolved, by keyboards, magnetic tapes, hard drives, screens and so on. These languages were rudimentary, and creating programs took time - you had to know what you were doing, you had to write the code by hand, tools like intellisense didn't exist, you couldn't just pull up a preview of another part of the code in another window, you had to be thorough to be successful. I remember doing a small amount of Assembler programming back in the early 1980s, and if you've never tried it - all I can say modern languages and computing are a thousand times easier to understand, read and code. Assembler is close to machine code - very much tuned to and aligned to the specific instruction set of the CPU you're working on. Again - time consuming, easy to make mistakes.

From the 1970s, along with the popularity and availability of personal computers like Sinclair's ZX series which you could plug into an existing home TV, programming languages started to evolve, as did the tools to support them.

However - BASIC was just around the corner. Standing for "Beginners All-purpose Symbolic Instruction Code", BASIC was aimed at making programming easier. Removing the ability for the user to make so many accidental mistakes, reducing the possibility of errors and lowering the barriers to adoption. You didn't need to be a professional programmer to understand and be able to write simple BASIC software. As a result, it was adopted widely and used by hobbyists for fun projects, and often business users to help them run their companies - my dad used to use dBase III (on a Sharp MZ-80B) for various book-keeping, payroll and inventory tasks to help run his bakery, for example.

And here's where we see the first real appearance of the split between what we now call the Pro-Developer, and, well - everyone else. Thanks to languages like C, which gave developers more control over the ever growing capability of the computers the workloads ran on, business and professional developers needed to keep learning and honing the skill and art of software development - understanding the nuances of how language features translated to the machine code once compiled, how to ensure maximum performance and memory efficiency, and making sure they stayed within the boundaries of safe execution and avoid fatal software errors (aka. bugs that cause crashes). Because BASIC had boundaries and hand rails, you weren't able to get as much performance out of your code, and you didn't need to be perhaps as careful as a you did with more advanced languages. And hence, C developers considered BASIC developers to be inferior, and hence my title bullet "And a bit elitist".

C continued to gain traction and evolved at pace. As with most languages around at this time, C is a functional language - the code executes in a procedural fashion and follows a clear, logical path. This model wasn't well suited to the kinds of applications and operating systems that were now appearing, which introduced multi-tasking and more complex user interfaces that allowed users more freedom of navigation.

Game Changer #1: Object Oriented Programming soon became the favoured model. It leant itself better towards more maintainable, modular software and allowed functionality to be grouped together in ways that minimized the need to duplicate code - through concepts such as polymorphism, inheritence, abstraction and encapsulation. This step (in my case, from C to C++) was a game changer. This was big - it made a huge difference in the time it took to build good quality systems compared to C - and suited the multi tasking, multi threaded environments like Windows and OS2 that were on the market, enabling programmers to worry less about having continually check with the OS whether a mouse click or keyboard press was queued to be processed by the application, and instead being able to delegate message handling to specific instances of objects. Object orientation also allows us to model real world scenarios, artifacts, documents or concepts into "classes" that make sense to us. A quick web search of polymorphism will soon show you examples of class Dog and class Cat, both of which are inhertited from class Animal. Programming was still an art, but the burden of time was now starting to swing towards design, modelling and arguing about how best to use the language and memory efficiently, as opposed to watching out for syntax and coding errors and the sheer volume of lines of code you had to type.

Game Changer #2: On the topic of memory efficiency - very hot on the heels of OOPS (Object Oriented Programming Systems) came the next big step change to make programming easier - Managed Languages. Java and .Net were designed with memory management built in. With C and C++, programmers had to decide how much memory to allocate, where to allocate it from, and track it's usage - and then remember to de-allocate it when it's no longer needed. Debugging "memory leaks" was common. Many applications made it to the market with leaks in, whereby if you ended up running the program for more than a few hours at a time, it would run out of memory and crash, you'd need to restart it (or in some cases, the crash would be bad enough to hang your computer completely needing you to reboot it). C/C++ became the tools for the niche programmers - those who needed very high performant code (perhaps for games) or to access parts of the hardware considered "unsafe" to provide deep diagnostic access. C# and Java, with their built-in "garbage collection" became the professional developer's languages of choice.

Then we saw the start of the war - Java vs C#. Still burning in some quarters today, you will find two distinct camps of developer, each of which loyal and devoted to their language of choice. Which is the "better" language? Well - I used to care, but now I really don't think it matters. However, both camps will definitely be united on one front - they are Professional Developers, while those using Visual Basic, Delphi and so on - are not.

IDEs, or Integrated Development Environments - became richer and richer, doing more and more for the developer, feeding the laziness and desire for the programmer to produce more with less effort. Wizards for everything used scripts to churn out loads of templated code. Built in hints, suggestions, access to inline help automatically and descriptions and examples of available parameters - all available in real time. Taking this further - tools to create the unit tests on your behalf by analysing your source code, real time syntax checking and error warnings - and then DevOps - automated, continuous integration of your source code, automated building and testing - and even deployment - all done simply by submitting your change into the source control system. Where will it end? Well - AI is going to the next level with systems like CoPilot, which analyse your entire company or project repository of source code, and actually does the programming for you based on the name of the function you've declared and were about to start coding!

At least it's still "Proper Code", right? My point is - the actual writing of code now isn't the chore it once was.

So programming is easy. But development, ie. the building of useful solutions, is not, and here's why...

In parallel to the evolution of development of course, hardware and systems infrastructures haven't stayed as they were in the 1950s. Mainframes were superceded generally by "mid-range" machines, then servers, and server farms. As networking and remote communication technology became faster and more cost effective, compute was able to be co-located to dedicated buildings (data centres), and now - Game Changer #3 - Hyper Scale Cloud compute with software defined infrastructure has become the mainstream way to host application and data workloads. Personal computing has continued to improve too, with desktop and laptop computers meeting and exceeding the power of those early mainframes in a very short period.

The human/machine interfaces I first used - a keyboard and a screen of 40 or 80 columns x 25 rows, meant that developers back then had to be very creative, in terms of maximizing that screen estate. The ZX Spectrum was one of the first to implement hardware "Sprites", graphical objects that you could define and animate for games - previously programmers would have to build graphics by redefining the alphabetic character map (UDGs). Today - the choice is immense. Think about the display on your washing machine, your mobile phone (3d touch enabled, perhaps?), the depth and breadth of colours available on your TV set or an electronic billboard in Picadilly Circus (or Times Square, if you prefer). Or how about the interactivity on a HoloLens? 3d holographic display with gesture and point in space detection and voice for input.

But it's not just about the human interaction piece - it's about the "things" out there that can be controlled and need management and operation - the breadth of devices, sensors and systems that are controlled by software is immense. Programmers don't just produce code to manage a shop's inventory or do some book-keeping; they are writing the control logic for an autonomous vehicle to safely navigate its way to a destination; or building a system that enabled the most efficient distribution of electricity across a network of disparate energy sources like solar panels or wind farms, to keep the lights on. Literally.

tAnd is why

And this is why I'm really pleased that programming is now easy. Programming has to be easy because development today is really hard - we don't want our developers to be spending time fixing syntax errors or looking up the order or name of some rarely used API parameters. Driving industries forward through innovation and transformation; driving sustainability goals, reducing environmental impact from the way we live today; making renewable energy capture more efficient - these are the kinds of challenges that are really important for developers and software companies to be tackling.

Professional Development today isn't just about programming. It's about integrating systems, designing and architecting broad solutions, tackling unique and new problems. It's about having the breadth of vision to be able to create new value that progresses technology - our know how and ability to achieve more.

The IT Industry is at breaking point. We need to make some changes.

So returning to my second title statement - the problem I'm referring to, broadly - is a world-wide lack of sufficient people that match that Professional Development criteria today. Those who can bring systems together in a cohesive way that creates something new and better than was there before. Creators, innovators, integrators, developers.

As a professional developer, the value you bring to your company is putting your skills to use by improving and iterating on the IP that drives the company mission. If your company mission is to produce the world's best accountancy software or inventory management system, and you're contributing to those projects, then crack on, you're doing a fine job. However, if your company's mission is "Connect people to what’s important in their lives through friendly, reliable, and low-cost air travel.", and you're developing a new report to save the finance team 15 minutes a month, I'd suggest you're not really driving the company forward, and your skills are not being put their best use. Another example I see regularly is product development teams being diverted from the company's main product (which brings in the revenue, and hence provides the return to cover the cost of the investment made in the development team as well as all the other costs the company bears) - to focus on writing code to provision a new account for the latest new-joiner to help the HR team's onboarding process. This not only costs the time of this iteration of the build, but that system has to be maintained, monitored and upgraded for the future of it's life.

I get even more frustrated when I hear of entire development teams being asked to build something specifically for an internal only benefit, where the requirements for that system are 95% met by commercial off-the-shelf software that already exists, and has already had years of investment by teams whose business it is to understand, build, maintain and develop that software.

So how we do we fix this? Remember that split I talked about between the Pro Devs and the hobbyists? For most of my career, I've considered myself a "proper" developer. I've worked on production software that's been the core IP for the company, and I've worked on inhouse systems that in retrospect should have just been bought rather than built. Today, I'm a manager and I'm not part of a development team. I still code, but I'm too dangerous to work on anything other than my hobby projects. But this year, I had an epiphany. I faced a problem at work, to which I could picture a solution, through software. For the first time ever in my career, I was able to implement this solution end to end successfully, without having to write a single program or a line of "real code". And I didn't cheat by using any other people in the organisation! I've always seen low/no-code solutions as being something not good enough for production environments. I've proved myself wrong, and happily now embrace this way of being able to solve internal business problems - rapidly and cost-effectively.

For the record, the process I built was this: a trigger executed when a sales engagement in one CRM system progresses to the next sales stage. The process then goes to lookup relevant details in a second CRM system, extracts and logs that data to a reporting database and automatically builds and sends an email with a nicely formatted notification to two account teams and the technical team with details of the engagement, including calls to action. This is a fairly simple scenario - but it's just the beginning. I've since been able to achieve much more, and improve the communication and engagement between teams, resulting in a better experience for our customers.

I know non-developers in other companies have also experienced how easy and rapid this process is (because I've seen it). It's empowering for them, and it's liberating for the development teams. The business users can knock themselves out building thier own reports, applications and business process automation. They can change their requirements whenever they like and make their own changes, they can still achieve what they need while leaving the developer team to get on with the important task of driving the company forward through core IP software innovation and development.

There is a slight catch - some work usually has to be done by the development team to provide an interface (API) for the business users to use, if one doesn't already exist and the business users need access to the the core IP systems. If the business users are purely automating things they can do today between non-core systems (eg. CRM, accounts, intranet, etc) then likely the development team don't need to be involved.

This new Utopia is called Fusion Development, and this is the future of where software companies (ie. pretty much all companies that develop software based IP) need to be. This is Game Changer #4 for our industry (at least, before Quantum computing is mainstreamed!).

Fusion development teams are a blend of people across the business who are empowered to use the Power Platform suite to solve their own business requirements. The dependency on the Pro Developers and IT Administrators is low, because the bulk of the work can be done by the business users.

Does ths whole pattern of non-professional developers doing development sound familiar? Well it should do - similarly to how my dad used to be able to write systems back in the 80s and 90s to help him run and manage his business, the barriers to entry for today's equivalent are low - the difference today though is the technology has matured, we're no longer talking about writing a program to control a single computer - what we're doing now is integrating and automating existing systems through pre-built connectors, using a solid, scalable and reliable platform - ie. solving problems using existing systems, and without having to write any code.

Don't do what so many other companies do, and allow your development teams to be diverted from the mission of the company. Empower the finance team to implement the most suitable off-the-shelf system for their needs, and build their own reporting suites and dashboards by extending it with the Power Platform. Leave them to integrate it with other systems and automate their standard business processes to save themselves time. Yes, provide APIs that give them a safe way to access the core IP systems and data, but don't get distracted from that core mission - innovating, transforming and driving the company's mission.

Our mission at Microsoft is fairly well know - to empower every person and organisation on the planet to achieve more - and the Power Platform takes a huge step towards doing that.

I'd like to finish up with some recommendations for you if you're interested to find out more about Fusion Development and the Power Platform.

There are a set of certifications that you can achieve online, starting with fundamentals (an overview of capability) through to "associate" - really understanding the breadth and depth well enough in detail. Each of these has a free online learning path that takes you through the topics with clear examples, videos and other resources.

The link above takes you to a free e-book covering the Fusion Development approach, again including samples, and walk throughs of how to integrate and automate.

And last but not least - The Azure Podcast, which you can subscribe to on your usual podcast feed, or if you prefer watching people having the discussion, find us on YouTube.?Each week we talk about what's new on Azure, and discuss a topic in more depth with a guest expert on the subject.??If you search for episode 410, or click here , we cover Fusion Development.?