Did Lincoln say that we hate all software at least some of the time and we hate some software all of the time? He would have. Thank goodness we can\u2019t hate all of it all of the time because, after we stumble on the right combination of clicks and keystrokes, most of it does magical things. Too bad the path to these results can often involve cursing and pulling our hair \u2014 especially when the code is homegrown.\nEven if we hate the experience of using major products, apps and websites, the software development ecology is often unfair to the custom projects that handle special tasks for enterprises. After all, there are hundreds if not thousands of developers working on the major software and services consumers depend in their daily lives. There are entire teams devoted to the credit card billing section alone and entire buildings of workers devoted to solving how to get people click 1 percent more often. But it\u2019s hard not to judge the smaller in-house projects by the standards set by these brigades of programmers.\n[ Beware the 14 reasons why software projects fail and the leadership practices that could sink your software project. | Get the latest CIO insights direct, with our CIO Daily newsletter. ]\nMany enterprises have a handful of developers, or just one beleaguered soul, working part time on a software project while juggling several others at the same time. The company\u2019s end-users, fresh from clicking on a major retail website or crafting a bit of wit for social media, switch tabs and expect the same level of polish from the in-house accounting shim running on their desktop.\nDeveloping software is hard, but it\u2019s even harder when your customers are down the hall and eat in the same cafeteria. When they hate your code, you feel it deep inside. It\u2019s easier to recover emotionally from a bad bug if you don\u2019t have someone mentioning it at the company softball game.\nHere are 11 reasons why users hate your software. Some are simple to fix. Many are just consequences of scale. Bigger teams are able to build simpler products and devote the time to polishing.\nToo much user influence\nDo you want to talk with your buddies from elementary school, or read updates about your kids\u2019 school soccer game? You\u2019ve got no choice but to log into one of the few major social media sites and play by their rules. If you worry about your privacy, want to express an emotion more complicated than a heart button, or upload a longer video in a different format, you\u2019re out of luck. The major platforms define their terms and the users must adjust.\nSmaller enterprise projects don\u2019t have that power. Their users aren\u2019t stuck with a click-wrapped Terms of Service. The team\u2019s boss answers to the big boss and the hierarchy can twist some arms when bonus time comes. It all adds up to a very different power dynamic when users don\u2019t have to take what they get and find a way to like it. Users must acquiesce when the big social platform sets the rules, but with local software, they can effectively push back. And if they can push back, they will start to obsess about details.\nIt\u2019s slow\nNot all enterprise software is slow. Some of the old stuff actually screams on the new hardware because the development team hasn\u2019t larded it up with features. But when new features roll out, it\u2019s not uncommon for everything to bog down.\nSpeed is just one tradeoff developers must juggle, and when demand for features grows, responsiveness and performance often suffer. Big teams can redesign along the way but smaller teams can\u2019t.\nThe only solution is to push back against some feature requests that will bog down user experience. If the new SQL queries will be filled with complex JOINs, push for something simpler. If the clever new button would require a chain of slow AJAX calls, say no. Time is the one thing that we can\u2019t make more of.\nIt looks old\nOld computer programmers often like to visit stores whose checkout software hasn\u2019t been updated since the green screen era because it\u2019s a nostalgia trip. No animated GIFs or really any colors at all. The screen is a matrix of monospace characters in a 25x80 grid. Plus, response time is outrageously fast because the network isn\u2019t jammed up with cool icons and splash screens.\nBut it\u2019s still a green screen. The bosses may like it because it works without major investment. The bean counters may love it because the development costs were paid off years ago. But the users are stuck living in the 1960s and some are going to complain. Oh sure, power users can memorize all the function keys to blip around the various screens, but the rest of us can\u2019t figure out just how to pull down on a menu \u2014 if that square over there is actually a menu.\nIf the bosses don\u2019t want to fix something that isn\u2019t broken, continue to remind users that it\u2019s superefficient. Print up cheat sheets to help people who can\u2019t remember what the function keys do. Another solution is to build a graphical shell that looks pretty but does nothing but generate commands to be sent to a hidden green screen session. It adds a beautiful facade without changing the guts. And if there are some folks that just love the old green screen, well, they can keep using it too. \u00a0\nToo much security \u00a0\nSome local projects suffer from too little security but often the problem is too much. The company isn\u2019t big enough to support a full tiger team, so they err on the side of extreme caution. Maybe someone once inserted a thumb drive with a virus and ruined that feature for everyone. Now USB ports are blocked. Someone downloaded a virus and now all downloads are banned forever. Many small teams act like \u201cDr. No,\u201d turning down requests and supporting only the most innocent features.\nThere is no simple solution. Users will hate being constrained by draconian rules but they\u2019ll be the first to freak out if their employee records leak out. The best you can do is concentrate the sensitive data in better protected systems so you can allow the users some flexibility.\nNo dogfooding\nTesting enterprise software is always a challenge and it grows in complexity when developers share few skills with everyone else. Perhaps your business is flower arranging, axe sharpening or butchering meat for creating gourmet dog food. Odds are high that the person building your scheduling software or internal database will know nothing about the work everyone else does.\nOne solution is to have the developer swap jobs for a week, but that doesn\u2019t fly when the jobs involve serious skills like long haul truck driving or airplane maintenance. Sometimes shadowing can suffice. Sometimes there are smart employees who can do a good job writing the specs.\nThe developers, though, are going to need to reach out and communicate. They\u2019re going to need to listen to their users and let the users tell them how to remove the rough edges and ill-conceived workflows of the tool. Improving these channels are essential. If the developers can\u2019t be forced to use their own code, they\u2019re going to need to talk to those who do.\nChanging the business is expensive\nYou can change the business to fit the software or write the software to fit the business. Often, the first would require retraining thousands of people and reworking many strange and arcane workflows that developed over decades. So the managers often try to get the new software to fit the old business and that means it mirrors the complexity that\u2019s evolved over the years. Sometimes when people complain about the software, they\u2019re really complaining about some odd practice that began decades ago and has now been immortalized in software.\nThere is no solution to this except recognizing that the software may just be revealing a bad or overly baroque practice of the business. If your users hate using the software because some part is too complex, maybe that\u2019s because the business is too complex. Use the hate as a signal for bigger changes.\nFewer rewrite cycles\nMany programs can be improved by a complete rewrite. I know one team that starts a new version each January 1 and generates an entirely new version each year. It\u2019s expensive but it fixes the bloating and the kludgy cruft that accumulates.\nMost companies can\u2019t afford this and if they can, they are often tempted to invest the money elsewhere. So the software gets older and older. There is no solution but budgets big enough to support a full rebuild. Until then, the users just need to accept what can\u2019t be rebuilt.\nAging frameworks\nOnce upon a time when the software was new, the developers chose a framework for the new code. The choice was smart \u2014 then \u2014 but the steam ran out. Maybe the framework company was acquired by someone who didn\u2019t care. Maybe it went broke because the framework management was squandering the profits on fancy trips to Europe? Maybe the open source community was poisoned by some toxic haters.\nWhen your team decided to stake the future of the company on this framework, it was a smart decision because the framework was amazing. But now it\u2019s being held together with strings and beeswax while the hacker wolfs circle the camp at night looking for the untended security holes. There\u2019s little that can be done to fix old mistakes like this. You can try to plan ahead for the future by choosing bigger, better supported companies or open source projects with broad support, but there\u2019s a limit to predicting the future. All you can do is consider a rewrite. With luck, you can save much of the business logic.\nExtra features\nThe company building the basic framework tossed in every feature they could imagine to satisfy the needs of hundreds of companies. Your company, though, doesn\u2019t use most of them, but they sit there gathering dust on the menus and, worse, confusing new users who always ask why the features are there. You can have too much of a good thing.\nSometimes these can be edited out or graceful shunted to a submenu out of sight. It may not be cost effective to rewrite the business logic, but often it\u2019s possible to clean up the menu tree and prune the options available to the average user.\nError handling\nExceptions and errors creep into the workflow all the time. Sometimes a link to a key database is broken. Other times the forms contain inconsistent values. Giving the user the ability to understand, work around, and overcome the problems is key.\nSmaller projects lack the debugging cycles to flag all of the possible errors and ensure there\u2019s a graceful way to recover. It\u2019s hard to know what is worse: no error message or a cryptic one with a strange number.\nTime is a big part of testing and debugging. The best solution is to create a good error reporting framework to encourage users to report their problems. Careful tracking and good documentation is the first step toward fixing these mistakes.\nLower budgets\nEven the most successful companies can\u2019t afford enough developer time to produce something in the same ballpark as the vast consumer products that serve almost half of the world. Large banks, trading multinational conglomerates and pharmaceutical companies are rich by anyone\u2019s standards, but they don\u2019t have enough spare cash to support serious development.\nSometimes the users just need to be reminded that the tools are built with a small budget. If the profits are healthy and the bonus pool is fat, maybe that\u2019s the price of using software that\u2019s less than awesome.