What’s an unpopular software opinion you have?

Please share!

Comments

[Matthew Bramer]

All front-end frameworks today are a waste of time to learn.

[Volkan Hallaç]

Kendi kendini silen yazilima ne dersin.

[Erebos Manannán]

I've got a few.

1. Windows is the best environment for developers to work in.

Linux isn't stable enough, I always end up spending a not-insignificant amount of my time having to figure out why my graphics drivers stopped working or some application isn't launching, or what to do to resolve the random new dependency to a library my distro isn't providing, even after spending a massive amount of time to getting a distro even running and after fixing all the compatibility issues with my reasonably standard hardware.

Mac often breaks standards that have been around for eons without a good reason, and doesn't provide you with the basic means to make your life comfortable, and Apple does not provide you with a sensible repair service that would be required for a machine you need to work with. I cannot afford my work machine being out for repairs at an unknown facility for weeks, so I pay for on-site support packages from e.g. Lenovo and Dell.

2. Popularity is a bad sign.

If something is too popular, you will likely want to evaluate it very carefully before taking it into use. PHP was popular, for the completely wrong reasons. Ubuntu is popular, yet for me it's one of the distros with the worst success rate of getting a working install just by launching the install image, and being Debian based means APT which is the worst option out there for a package manager. Java is very popular, because the wrong people are making the decisions.

Typically how I see something being "the most popular x" is that it means it's been selected by people who don't know what they're doing and you don't want to repeat their mistakes. Research for yourself, maybe you'll end up with the same choice, but probably not.

3. Paid solutions are (often) better than free solutions.

People often flock to a "free" option for something. "Free operating system" means nobody is motivated to build a coherent experience that (mostly) just works out of the box. "Free editor" means sacrificing your performance to use Notepad++ instead of JetBrains IDEs. "Free database/monitoring solution/similar" means you need to figure out how to host it yourself - this is not in your expertise and if you can afford it, it's better to buy a paid service and focus on what is. I just don't have the time to use a "free" solution if a good paid alternative exists.

I pay for Windows, JetBrains IDEs, Photoshop, Slack, virus scanners, password managers, and many other things where free options would exist.

4. Git sucks.

Git is one of these examples of popularity not being a good sign. It's popular because people don't think, because "everyone uses Git". Yes, Git has a few decent ideas, but nothing unique and actually worth a damn.

What you should would want from your version control system, is that it follows the DVCS workflow for sure, that it works as well for all your developers regardless of their platform of choice, and that it works with you when you want to extend things.

Mercurial does all these things incredibly well, there's a few other options out there that do a pretty good job at it as well, but Git really is not among them.

Git is headed by a kernel developer, a person who has no understanding of a "human interface", and doesn't care about other people's problems, and it shows. If it runs on Linux, that's all that is required. The hook system is near impossible to get to work on Windows properly without some incredibly bad and broken hacks (pre-commit somehow achieves a fairly functional system but I don't yet know how). It is not particularly extensible, everything is based on a really broken implementation of some Unix philosophies of magic filenames and putting binaries in specific locations. Git's commands are nearly incomprehensible, and there's a lot of situations where you just have no idea if your changes are going to be deleted or what will happen.

Due to Git's popularity, the only decent Mercurial hosting, BitBucket, is now being terminated, and the world will become even more dominated by Git, which is clearly the worse option of the two, and there are other options out there that are probably even better for your use case.

5. If you don't use a GUI for your version control, you're doing it wrong.

Command line utilities have their place, for sure. A version control system without a powerful CLI is not worth using. However, when you are actually working on your code, you want a powerful GUI that is showing you which changes you made, gives you quick access to full visual side-by-side diffs of the files, and allows you to spot your mistakes before you commit them.

If you do not do this, you are doing it wrong, plain and simple. I call it "blind commits" when people just do something like git add . && git commit -m "Latest work" (and often add a git push -f because that's how they roll, then make an alias of the whole thing for "efficiency" and are spreading it proudly with their colleagues). You should always check through your changes, you are not the programming god you thought you were, you make mistakes, you forget to finish some changes, you left that debug statement in, etc. - check it before you commit it. CLI diffs just don't give you the full picture in a clear enough manner for them to be truly useful.

5. Web and application frameworks are overrated.

Microframeworks and overall DIY solutions can often get you where you need to be faster with less dependencies, and with a better end result. You should always pick the smallest base to build on instead of starting from Django, Electron, or other such monstrous framework.

6. RDBMSes are almost always the wrong choice.

The benefits of a relational database are basically about consistency guarantees and such, but they are impossible to implement in a manner that scales, so instead you end up with a restricting database with tons of behavior that does not help you make your software better.

7. Scrum and other processes are overrated.

You don't need a strict process of any kind if you have a competent team and good leadership. Fire the bad actors in your team, then hire better ones, and you don't need to implement Scrum, SAFe, or other such things. If your team requires strict adherence to a process to deliver, maybe you need to think of working somewhere else.

8. Not all people should be tolerated in a team.

If your teammate is wasting everyone else's time because they can't understand the documentation, it might be that your documentation is bad, or it might be that this team member is going to slow everyone down and produce little or no benefits to your team. Figure out which, and fire them if necessary. There's also other ways people are under-performing, or causing other problems with your team - get rid of them and give the rest of your team a high performing highly motivated environment to work in.

9. Your personal preferences don't matter.

You might like { on the same line with the function body, you might like it on the next line. You might like semicolons in your JavaScript, you might hate them. I know you really love to align your data structures neatly, who doesn't like to see

foo = {
    "key":      "value",
    "long key": "another value"
}

None of this matters, it's not worth your time to focus on these things. Use a code formatter whenever possible, gofmt, black, prettier, clang-format or whatever works for you. If your language does not have one yet, think of building one. If you're designing your language, make sure it has one standard and make a formatter for it. Better yet, make it refuse to run code that isn't formatted - problem solved forever.

Code formatting is a question people spend way too much time fighting about, with too little gains. Pick one way to format things automatically, enforce it via continuous integration and pre-commit hooks (e.g. pre-commit.com or in a better system like Mercurial you can do it more easily).

10. You should think hard before you start a project.

Want to start a project? That's great! Now stop and think about it. How long do you think it will really take? Ok, now double that, because there's always complications. Do you really want to commit to that amount of work, just to start with?

Just want to try and learn something new? Great, that's a fine option too. But are you really learning, or just copy & pasting? Did you come up with a unique idea that you want to build, or are you going to just follow a tutorial? Also are you sure you're learning the right thing, is this something worth spending your time in?

Are you hoping to make some money with it, sell it maybe? Do you have a plan on how to do that? Do you understand marketing? Do you know how to deal with accounting? If not - start with these questions first, and only when you understand how to actually launch something successfully, start coding for it.

In many more serious cases, you also want to think about the design in advance - is concurrency a specific issue you need to deal with? How are users going to interact with it? What platforms do you need to support? Other such questions should be considered, only then can you make the right choices for your project.

There's reasons you might want to still start the project, but starting a project and not finishing it is a good way to demotivate yourself from starting another project in the future.

11. Customization is bad.

If you customize your shell and use a lot of aliases (I draw the line at like alias ls="ls -lhaF" type of mostly insignificant default options, alias rm="rm -i" or rm -f is too much though), you need to put extra effort into thinking about how to help your colleague when they need help, or when using a shell on your servers, or other environments. Even distributing your own configuration to your computers in a reproducible manner that survives reinstalls, buying new computers, and so on is a lot of work that is often just not worth it.

If you customize your IDE to work differently from your colleagues with a bazillion plugins and such, you will be confused when trying to help each other.

If you spend a lot of time and effort personalizing your desktop or application preferences, it's gone sooner or later anyway, or you'll end up changing your mind and tweaking the personalization instead of spending time on useful things.

This is where I waver a bit myself though - because IF we had good ways to reproducibly distribute your configuration for all your applications, for your shells, and so on, then it might be a bit less of a hassle and more worth it. However, right now it's not exactly easy. There's Nix but it doesn't take care of everything.

We need to build more standardization on where software configuration lives on all OSes, and how the personalization can be securely and privately synced to a safe storage, while allowing us to share certain customizations with other people. If we achieve this, then the time would be much better spent.

But you should still not customize your shell and use excessive aliases 😄

12. You should host the things you know, but nothing else.

Not quite sure how popular this is, but it sure isn't being followed by a lot of people. Don't host your database, let someone else worry about that. Don't host your metrics collecting software, it's not your area of expertise. Host your own load balancer, host your own application containers, and anything else like that that YOU directly work with to implement your software.

[JasperHorn]

Typescript is only "mostly" typesafe: you're better off just using plain old javascript and understanding its limitations than using that leaky abstraction.

[Björn Grunde]

Too many developers don't go outside their comfort zone to find the right tools for the job or learn new skills. They rather stick with the same old stack with a strong belief it will solve anything. Even if the project ends up unnecessary complicated.

[ca55idy]

The Spring Framework shouldn't be used for everything in Java

[Lautaro Lobo]

We should all learn HTTPS.

There's too much JS on the web.

[Graham Trott]

1. That the majority of programming problems - especially smaller ones - can be defined unambiguously in English. Not as concisely as computer code, of course, but if you go down that rabbit hole you end up in a land of impenetrable formulae.
2. That if you and I can understand unambiguous English there's no good reason why a computer can't. This is 2019, after all, not 1965. We've spent all those years making computers cleverer (my phone can not only hear but understand me when I speak to it), but when faced with programming problems, instead of getting them to use our language we force ourselves to become machines and work with ever more complex computer languages. Which only a small minority can do, so maybe maintaining exclusivity has something to do with it.
3. That when computers speak the language of their users, software is a whole lot more accessible (skin in the game) and reliable (more eyeballs, fewer bugs).

My 2¢.

[Calleio Kismet]

Frameworks are silly. Just use libraries.

[Supriya Srivatsa]

Loose and dynamic typing aids in writing fast code, but it is difficult to catch bugs early, uphold quality and ensure no runtime errors/crashes.

[Isaac Welch]

Inheritance is an anti-pattern

[Ross]

1. Code that takes up less space is not instantly easier to read
2. Functional programming isn't the next big thing and wont be until it's intuitive
3. Squash commits for PRs are lossy and therefore stupid
4. Code is NOT art
5. Agile is not a set of processes (it's not standups, scrums, sprints or retrospectives of any combination of those things)

[Mark Sta Ana]

All code is technical debt.

(Yeah I’m that dev who would rather reach for others work rather than roll his own.)

[Pankaj Doharey]

I once gave Interview at Oracle Cambridge, the a*-wipes think private functions should not be tested because you will call only the public functions.

My Answer : Well, that doesnt mean we dont modify private functions. Use whatever is at your disposal to test them for Ruby use method send, For C# InternalsVisibleToAttribute, For Java Reflection. Do what is required to test them.

[Jayme Edwards 🍃💻]

The less planning we do, and the more we value diversity, the more innovative (and profitable) products we deliver.