Developers Are Creating Problems for Themselves and Companies
Last night I gave a talk at a developer meetup group in Liverpool after being asked to speak at the event. The developer group was full of extremely amazing developers who are far more knowledgeable than myself about the finer workings of high end technology. Hats off to them.
After listening to another speaker at the event before me, it was extremely clear that I had just sat through a talk for an hour and I honestly couldn’t tell you anything about what I just listened to. It was very abstract and quite frankly, way over my head. This is not a criticism of the speaker, he was great and the audience loved it. Here’s the thing though, I like to classify myself as a very knowledgeable person working with various technologies on a daily basis, I’m certainly no-where near as smart at tech as many of the people in the room which is a great position to be in as you can learn from them.
So anyway, I jumped up to do my talk titled “Venturing into the Unknown Building TendoJobs.com” which was designed to be an overview of building a tech startup from scratch while bootstrapping everything from day 1. I do a lot of talks to businesses, companies, conferences, events and so on, I enjoy doing them and sharing my thoughts with those interested. This one was different though, it was clear that the audience was so unbelievably amazing at various technologies that for those in the audience listening to me the content of the presentation must have been similar to a University Professor attending nursery to learn about something. It was fun doing the talk that’s for sure and it was truly a baptism of fire. What struck me most though was the array of endless questions at the end of the presentation. Rarely do you end up answering questions for a good 15-20 minutes at the end of a presentation, but they kept coming, which was great as it got people thinking.
As the old saying goes, to a man with a hammer, the solution to every problem is a nail. And this couldn’t be truer than within the developer community across all platforms and languages. The problem I see time and time again from developers and technology startups that I speak to on a regular basis is that they keep adding technology to solve a problem when actually you don’t need to add technology. At the development level, technology adds complexity to every project which adds time and money to what is being done. It’s time as developers we step back a little and start to ask ourselves what we are really trying to do.
To put this into perspective, here are just a few of the questions that came from the bemused audience last night;
- So what tools / technology do you use for your release and deployment process?…. i.e. expecting the sophisticated answer for something like Jenkins…….We use SFTP (for the non-teckies reading this, picture the process being viewed as a stone age person using a flint bow and arrow to catch an animal. It’s functional and it works. )
- When you make a change within the code, how do you know that it doesn’t break anything else?….. i.e. expecting the ‘best practice’ answer that every single unit of code has unit tests wrapped around them and we run these tests before we push code live…… We just build the code well and remove virtually all dependencies throughout the various classes (for the non-teckies reading this, imagine that you’ve baked a cake. Wonderful. Now your unit tests can be loosely thought of as checks at the end to make sure what you’ve made is correct. So in this random example, you’d line up all the raw ingredients next to your baked cake and confirm that they are present within said cake. This needs you to buy two sets of ingredients to test that the cake contains them all. Thus doubling the cost of the cake baking project)
- When you added this form to the website in the first instance, why didn’t you build in validation checks at every step from the outset?…. i.e. expecting that it was something we simply forgot to do….. We actively avoided doing this because we would have been building features and functionality that people may or may not have needed. Instead, we let the data tell us what validation checks we needed to add in as and when people started using the platform (for the non-teckies, this is talking about the ‘you must enter your First Name’ type notifications that you see on websites)
- So what frameworks did you use to build the platform? ….. i.e. expecting a cool and sophisticated answer about one of the endless technology frameworks available to choose from today….. We didn’t use any. We just used solid Model View Controller design patterns to structure our code well so that it is maintainable, easy to manage and release changes. (For the non-teckies, think about this as following a recipe. When you have your raw ingredients in the kitchen, which cookbook do you choose and which recipe do you select from them? We simply threw it all in the pan and it turned out beautiful)
- Why aren’t you streaming your file uploads via Amazon S3 and automatically resizing images as needed within the applications? ….. I.e. expecting to hear that this is in the pipeline to do so….. Because that is simply too much work involved to do and virtually all employers can manage to upload their logo within the guidelines provided. It’s needless work.
Above is just a small selection of the questions that were asked and discussed after the presentation. It was really interesting discussing the whole tech startup process with a group of highly experienced developers. I was certainly the caveman in the room without a doubt when it comes to tech which was really interesting.
The key message from the presentation though was all around Keep It Simply Stupid. You see, when you add complexity into any project, is it any wonder the costs of said project goes up when you then have to spend 50%+ more time developing the project, and is it any wonder that you cannot find the right talent within your organisation who has 5 years experience using technology X. You’re adding complexity out of striving to continually improve development techniques. I’ve seen this on many occasions in very large organisations where the organisation simply revolves around the digital technology hamster wheel to keep rebuilding technology and adding new and different processes into the system instead of truly stopping and thinking about what they are actually doing. Ultimately achieving nothing while working at 150% of capacity continually wondering why nothing is being achieved.
Ultimately the product or service is here for the user of the end user, the customer. You have to ask yourself that when you are looking to implement technology X or process Y within your application, does the end customer really care and are they even going to notice? If the answer is no, then honestly, what are you wasting time even doing it? Seriously. Sure, if you’ve an endless budget and lots of free time to do this, great, you probably work at Facebook or Google. For the rest of us though, let’s bring these dreams down into the practicalities of the day to day.
To put this into perspective, let’s just take a look at one of the largest developer surveys that takes place each year from Stackoverflow, here are some of the most popular technologies in use today;
.NET, ABAP, Android, Android Studio, Angular, AngularJS, Arduino / Raspberry Pi, Arrays, ASP.NET, Atom, aurelia, Bash, C, C#, C++, Cassandra, Clojure, Cloud, Cloud (AWS, GAE, Azure, etc.), Coda, CoffeeScript, ColdFusion, Cordova, Count, CSS, D, Dart, Delphi, Django, Drupal, Eclipse, Elasticsearch, Elixir, Elm, Emacs, Erlang, F#, Fortran, Git, Go, Groovy, Hadoop, Haskell, HTML, HTML, CSS, IntelliJ, iOS, IPython / Jupyter, Java, JavaScript, JQuery, JSON, Julia, Komodo, Kotlin, LAMP, Lighttable, Linux, Lisp, Lua, Matlab, Meteor, MongoDB, MySQL, NetBeans, Node.js, Notepad++, Objective C, Objective-C, OCaml, Other, Perl, PHP, PhpStorm, PL/SQL, PostgreSQL, PowerShell, PyCharm, Python, R, Raspberry Pi, React, Redis, Regex, RStudio, Ruby, Ruby on Rails, RubyMine, Rust, Salesforce, Scala, Sharepoint, Smalltalk, Spark, SQL, SQL (or SQL Server), SQL Server, SQL Server & SQL, String, Sublime Text, Swift, TextMate, TypeScript, Unity, VBA, Vim, Visual Basic, Visual Studio, Visual Studio Code, Windows Phone, WordPress, Xamarin, Xcode, Zend.
The above really is just the tip of the iceberg when it comes to technology choices. Within each of the technologies above, there are equally as many variations, technologies, frameworks and best practice ways of doing things. Technology quite simply is a minefield. I work with technology on a daily basis and I’ve only ever heard of around 50% of these technologies, let alone had the time and inclination to explore them.
Look, I’m not saying that all of these best practice things aren’t something to work towards. They all have their benefits. But let’s be realistic here, every single project is limited based on time and money which ultimately determines the output at the end. You cannot, and I’d argue should not, implement best practice from day 1 for anything, unless that thing is as simple to implement best practice as it is not to. Keep things simple, use solid continual development and agile processes to build on solid functional foundations.
Adding complexity to any project is a risky route to go down and one that I’d always recommend steering away from. Keep your projects as simple as possible instead of keep trying to add in new technologies into the system endlessly just because you can.
A couple of comments from the questions on the evening put this into perspective which include “You had some balls to stand up and do a talk like that in front of a group of specialist developers” and “Your ideas are certainly…. Interesting”, which is a polity way of saying they are a bit “out there”.
One final thought I’d like to leave you with. Technology projects, systems and organisations are as complex as you make them. You cannot then wonder how you’ve got into this position and complain about how difficult things are. Take a staged approach with developing and continually improving any technology system instead of simply bolting on as many pieces of technology as you can just because they are cool to do or are deemed best practice. Save yourself endless hours, weeks and months of time building things that ultimately adds no value to the project, adds cost and makes everything difficult to maintain.
Great talk, great group of people, great discussions. Food for thought from a different perspective. See everyone at a future event.
