Asking a 1,000 Developers What They HATE About Software

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
a few weeks ago I asked a question on Twitter what's the one thing in our industry that everyone seems to love but you hate so Hate's a big word but it is Twitter and nuances not really Twitter's thing the Tweet got lots of views and lots of responses so I thought that it might be fun to look at a few responses in a bit more detail and add my thoughts to them so here's my take on the things that we love to hate in software development foreign hi I'm Dave Farley of continuous delivery welcome to my channel if you haven't been here before please do hit subscribe and if you enjoy the content today hit like as well if you don't follow me on Twitter you can find me here or on Mastodon here I suppose that I should start by admitting that while there are things that I hate I'm not much of a hater when it comes to soft software development really I do get exasperated and annoyed sometimes and I'm certainly opinionated but mostly I agree with this for this video though though I thought that I'd group some of the responses together and then talk about those topics and why they may or may not be justifiably hateful things I came up with 15 groupings and one of them's misc so the divisions fairly arbitrary really I do guess that our first observation is that there is a lot to hate before I go any further though let me say thank you to our sponsors we're fortunate to be sponsored by equal experts trisentis transfig sleuth and Ice panel these are all companies that offer products and services that are well aligned with the topics that we discuss on this channel every week so if you're looking for excellence in continuous delivery and software engineering do click on the links Below in the description one of our long-standing sponsors trisentis is expanding its learning communities and just launched a new community shift Sync It's a community for anyone interested in all aspects of quality software engineering the platform features engaging content user forums and Industry expert contributions so whatever your role if you're interested in doing a great job check the shift sync community and there's a link to that below as well the biggest single-hated group is a bit of a catch-all that I've called process this was actually a lot bigger until I decided to separate management out I guess process is an inevitable category one of my friends with some justification says everything is just people processing things really but by process in software terms I mean the way that people organize their work in this list the hate seems pretty well spread but agile and waterfall get called out specifically multiple times on the whole I think that agile as an idea has earned and gets a pretty bad rep but I also think of myself as an agile proponent I completely understand the reaction to the industrialization of what someone called faux agile but I do think that at its heart a genuinely agile approach is still probably the best one so I believe that developing with agility was a significant step forward for our discipline I do hate what it too often becomes when shoehorned into corporate cultures that don't understand what it takes to build good software though do I hate waterfall I'm not sure that I hate it as much as seed is somewhat ludicrous I feel sorry for people who work in waterfall processes if I'm honest but I struggle to understand how anyone sees it as a good idea for software but they do it seems such a fundamentally poorest fit for software development to me these days waterfall is usually practiced under some kind of agile disguise usually disguised as scrum or safe in some form but underneath it's still waterfall people also called out hate for some more specific aspects of process code reviews estimation and blindly misapplying the latest fads from the big web companies I guess it depends on what you mean by code review but no I don't really hate code reviews in fact I want to do them all the time in the form of pair or mod programming is usually my preference do these haters hate code reviews in general no feedback from me thank you very much or do they really just dislike the poor version of code reviews in which case I can sympathize these so often take the place of real useful feedback I like working collaboratively but I do want good feedback not some kind of pro forma checkbox kind of review that last one here blindly copying the famous web companies yeah I agree maybe not hate but serious dislike at least I can't tell you how many companies I spoke to a few years ago that proudly announced to me that they were following the Spotify model of development by which as far as I could tell they really meant that they'd renamed their teams to tribes carried on with their faux agile water scrummer for and expected different results anyway software development is not a cookie cutter process you can't blindly follow a recipe which is reflected in some of the other categories for hate I'd say that microservices are one of the current examples of that Spotify style mistake just because this is a good strategy for companies that operate at a global scale with tens of thousands of developers doesn't mean it's good for a small startup I can't hate micro Services though because for some situations like being Amazon or Netflix they are a great idea another technology that is perhaps in this category is kubernetes again I don't personally hate kubernetes but I think that I can understand where the hatred comes from this is another example of one of those fashion things I've seen so many simple applications some of them that could have been written a single process systems that seemingly started out with the question in the people's minds we've got the kubernetes in place now what's the problem again there's no one-size-fits all there is no successful web monster that started out with a globally scalable system the scalability comes later if your team is never going to scale to more than a few tens of people and your code is never going to be used by more than a few hundred or a few thousand you probably don't really need micro services or kubernetes so while I don't hate either of these I do rather dislike their misuse quite a lot much better to pick the technical approach that makes it easy to solve the problem that you have in front of you now not the problem that Google has even if that is the problem that you hope to get to one day I recently posted an episode that asks why people hate JavaScript when it is so widely used one theme in the comments to this was but I like JavaScript sure not everyone hates it but it's still pretty commonly despised JavaScript was called out for derision explicitly by lots of people in response to my tweet watch my JavaScript episode to see what I think I don't hate it at all but do rather wish it was a little bit better I think that the next category is pretty closely related to the JavaScript ecosystem but isn't exclusive to it it's Frameworks I can't really say that I hate Frameworks in general but I do come pretty close of course I don't want to have to write everything for myself I want to reuse other people's code but I do much prefer to do that on my own terms I'd say that the difference the defining characteristic of a framework versus other forms of code sharing is that a framework defines some aspect of a programming model that it forces it forces you to to adopt if I use a library I'm still in control of my design choices if I adopt a framework I have other people's design choices forced on me to some greater or lesser extent I prefer the Unix design philosophy I'd rather have a collection of pieces that I can organize and structure as I see fit given the problem rather than be forced to comply to somebody else's design ideas this isn't always true I'm not wholly consistent in this if the framework is not too intrusive if I can isolate the programming model it forces on me to some edge of my system or if it's so wonderfully written that I don't care about the programming model or does something so important then I may change my mind and use it anyway but on the whole I nearly always start out being skeptical of Frameworks and trying to wonder how can I can isolate them in in their use in my system so I do some somewhat sympathize with this group of haters a bit incidentally react got called out specifically quite a lot in this category inevitably the people that follow my content here are and on Twitter are a self-selecting group mostly more experienced people mostly men apparently and mostly I assume aligned with the kinds of ideas that I generally talk about so I guess the fact that one of the biggest categories for hatred is feature branching and pull requests is not a huge surprise I have several videos on these topics and um certainly and see both of these practices for team-based development I can't say that I hate them though I've certainly worked on projects that did both of these things and once or twice things that were worse but I can't love them either I can understand that feature branches and pull requests make sense for open source projects where we don't know and don't trust the people that are making submissions but I think that they're otherwise used as a kind of crutch to lean on rather than fixing real problems when used inside teams they give the illusion of safety at the level of individual developers I'm okay what I don't care what you're doing but at the expense of effective and efficient teamwork and I think that a good professional development is mostly a team game so this matters I've been accused of being somewhat dogmatic on this point and while I don't think that I am I think it is a fair criticism because I imagine that I can sound dogmatic sometimes but here's my position if you're working as part of a team that practices feature branching and pull requests then I think that you can do quite a lot better that doesn't mean that I think that it's impossible to build software with feature branches and pull requests of course you can but the data and my experience is that if you with your team and your technology and your problem could compare yourselves doing feature branching and pull requests to practicing full full-blown integrate at least once per day continuous integration then the second version of you would win producing better software faster does that mean that you can't do a good job with feature branching no but it's harder to do a good job and ultimately even if you are already doing well you could be doing better I don't despise people who practice feature branching and pull requests I think that they're misguided I do get exasperated by poor arguments in their favor though you aren't going to convince me that you're right about feature branches and pull requests by calling me names or telling people that I've never written any real code I've tried most of the Alternatives when it comes to software development approach and I try to recommend the things that I've seen that have worked best for my teams and I prefer to use data as well as some insight into how and why these things work better so it's fairly easy to change my mind show me where my idea and or my reasoning is wrong and if you can back that up with data or other evidence or the better personal experience and personal taste yours or mine isn't enough because inevitably I'm going to value my personal experience and my sense of taste more highly than I value yours it would be kind of weird if I didn't right my model for this stuff is based on the central importance of fast high quality feedback this is at the level really of control systems as much as people if you have a system any system you'll be able to exert more control if you get faster feedback that is the distance between the action and sensing the result of the action is short so if we make a change to our software we'll be safer move more quickly and more clearly understand the impact of the change if we can sense that impact very quickly feature branches and pull requests slow that feedback Change My Mind by showing me where this logic is run so I don't hate feature branches and pull requests but if you love them give us some better arguments in their favor the next grouping of things to hate is tools and tools with a special shout out for jira as it turns out to be honest apart from jira this is a pretty random collection I assume that the people that call that computers for hatred were doing so somewhat ironically I certainly swear at mine from time to time python exposed my bias I was surprised as I quite like python one thing that I don't like though is our obsession with languages in general I wish we discussed and argued about software design as much as we do about languages I get it of course I do talking about languages is fun sometimes but I often feel that the minutia of distinction between them is largely irrelevant I think that how we wield our languages the shapes that we make in our software is much much more important than the languages themselves I guess that we get attached to the tools that we use or not and because we're using them so much we make strong opinions as a result which brings us into jira I'll confess I don't really like jira very much either jira seems to me to suffer from that common problem of software that's been successful it tries to do all things to all people I guess you don't get to be a market leader by picking a small niche as a result jira promotes ideas that I really don't like very much but the real problem is mostly how we use it rather than what it does I think one of the difficult things in software development is finding how we can minimize effort and so I assume that the reason that people dislike jira quite so much is because this is the primary interface with usually a poorly constructed bureaucracy created to manage change I strongly sympathize with this view but is it jira's fault really or is it our approach to bureaucracy that's the real problem I think maybe the second one I like to try to optimize our development process to minimize work while maximizing benefits so I much prefer it if I can make for example status tracking a side effect of how we work normally rather than making it an explicit task in its own right for example if I have a deployment pipeline that determines the release ability of my changes which is how I Define a deployment pipeline then if the automation says everything's good the automation can mark it as good too there should be no need for me to log into jira and update a status of a task to say that it's ready to release so I assume that when people say that they hate jira what they really hate is the burden of bureaucracy associated with software development or maybe that's just me my hate category of coding is diverse I love coding I don't think that anyone here would claim to hate it really but some people hate aspects of it for example I agree that I dislike messy code my office is a pretty messy place I'm not the tidiest of people but my code is tidy I have a series of internal rules for organizing my code that that I pretty much stick to I'm pretty diligent with that I really don't like it when my code breaks those rules I don't like multiple return values much I have some kind of ordering scheme in my head for functions and parameters hard to express clearly but I want important functions high up in the code so you read them first and I want the parameters obviously to be as few as possible I also want them in order of relevance for the function so yeah I do hate messy code I quite like programming in scripting languages sometimes I tend to gravitate towards python as my default scripting language but my bias is strongly in favor of more strongly typed languages if I'm working as part of a team if I have the choice I'm mostly right to throw away code in Python but I want types for commercial things types give me faster feedback on mistakes and are a lightweight part of design by contract which I like quite a lot I can't say that I hate either one though when I'm being introspective about what I do I probably think of myself most strongly as a software designer rather than as a coder it's not that I don't like or don't write code it's that I don't make a distinction between code and design and design is the interesting and valuable bit in my opinion code is really just how we write down our design ideas it's not some diagramming technique is the real language of designing software which brings us to that blurry boundary between coding and the next category in our hatred design I probably most strongly agree with David here I do hate code that wanders around with no sense of direction we need organization and structuring our code that helps us to navigate and ultimately better understand the problem that we're working on this is what design really is in my view I think that the defining characteristic of high quality code is measured by our ability to change it easily and safely and with confidence dependencies are a pain particularly if not well managed but I'd probably call out coupling as the real threat coupling compromises our ability to make changes and slows our ability to make progress and gather feedback I have left the two categories that I most strongly agreed with to last the first of these is hype yes I hate the hype that surrounds our industry we're an industry of fads and fashion we talk all the time about the rate of progress but the fundamentals of software development don't really change much and when they do they change quite slowly but we mostly don't seem to be able to learn these fundamentals very well because we focus on the shiny constant Deluge of fashionable changes instead we constantly repeat the mistakes and of the past and fail to learn the lessons the problem with this analysis is that it is noise true there are step changes that happen in our industry changes that revolutionize the world but we do often conflate the changes in Hardware which does progress exponentially with changes in software which don't there are certainly differences in improvements in software developments that happen from time to time but is the way that we code the UI on a mobile modern mobile phone substantially different two or more efficient or more effective than how we coded guis in the 1990s really they're certainly not different on the same scale as comparing the difference between a computer from the 1990s and say a modern smartphone software Advance happens differently and not always at breaknick PACE but still there are sometimes big changes the move to the web was one the growth of Evermore capable operating systems and more recently cloud computing are other examples the hype is kind of inevitable I suppose but I do hate the impact that it has and one of the impacts that I dislike that it has is that it often obscures real inflection points in the history of software I dislike much of the hype currently surrounding the advances in artificial intelligence but I am still still pretty convinced that this is one of the biggest changes in human history this is one of those inflection points and that in this case it's ha it is happening at an exponential rate because it's not us that's writing the software it's the machines and so in this particular case boring isn't the adjective I choose the last category the category against my unequivocal support is complexity yes I hate complexity complexity is the enemy that we're trying to eliminate or at least tame when I was working in development teams I used to say things like yeah it works but we aren't there yet it's not simple enough if we're striving to keep our software high quality and so being easy to change then the best way that we can do that is to make the software as simple as we can simple takes time great design is where you can't remove anything more without reducing the utility of the thing that you're designing so if code is designed and great design is as simple as we can make it then our job as designers is to fight the complexity and seek the simplicity I hope that you enjoyed this fast tour through hatred thank you for watching and if you enjoy our stuff please consider supporting our work on this channel by joining our patreon community there's a link to that in the description below yeah foreign
Info
Channel: Continuous Delivery
Views: 26,483
Rating: undefined out of 5
Keywords: software developers, software engineers, software developers hate, bad things about software engineering, cons of being a software engineer, programmer, software engineer day in the life, software developer career, software engineering jobs, computer science, software engineering, software development, Dave Farley, continuous delivery
Id: aSjUxRAUcBM
Channel Id: undefined
Length: 23min 48sec (1428 seconds)
Published: Wed May 17 2023
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.