This page is archived, my current opinions may have changed.
There is no one right way
People tend to complain about programming languages and techniques. There is no such thing as the best tool. It is more important to have the correct people rather than the best technology. The tool which someone prefers is different for everyone.
Modern tools and languages are often better optimized, quicker to develop with, and have learned from past mistakes. Although it is good to keep in mind that modern is not always better. There are always multiple options to consider. Rewriting legacy code can be worth the time, but it highly depends on the situation.
A similar issue occurs with programming styles. The formatting of code, and the design patterns someone uses. Experience is more important. Yes, certain things have more benefits, but trying new things does not hurt. Seek the right people.
Software quality
Software quality comes down to finding the correct people. At the end of the day your job is to make a working product. The following factors are important:
- How good can the programmer(s) program (having a degree doesn't necessarily mean that you are good at it. Experience and knowledge can help a lot.);
- How much do(es) the programmer(s) know about the project (It is useful to know something about money if the tool in development is a money management tool or something);
- How good the programmers work in team (if there is a team);
- How much motivation the team has to develop the project.
Try to avoid
Avoid complaining about the smallest things. Formatting code in a certain way does not change the logic code. You don't use the "cloud". That must mean that you are a bad programmer. Enough! It is common for people to spread nonsense about programming. You are not superior because you use a certain technology. Idealism is pathetic.
It is not a miracle that methodologies are filled with nonsense. They are often pushed by people who haven't written code themselves. What do they know about development? Planning methodologies shouldn't be treated like a religion! Having a plan and a goal is great. But a plan should be optimized for your team.
Using difficult words can make communication with the team harder. Buzzwords are often used to look smarter. They are often used wrong. When that happens using such words can make you look dumber. Terminology should ideally be clear to everyone in the team. Words do create a personal style, but difficult words should be used in the right context. Towards certain people. Buzzwords do have a place in marketing though.
A tale of two friends
Two big paradigms have been born since programming came into existence. Functional programming and object oriented programming. Often these can work well together. More often than not the people who follow one of these two leaders do so religiously. These two camps often fight wars.
Both of these guys have their uses, and their audience.
Pure object oriented programming
Object oriented programming is easier to learn, but not easy to do well. Design patterns are often used to patch up some of its problems. But those can make things more complex as well. Objects cause side effects, and exceptions are common.
Pure functional programming
Functional programming is more like math. This is harder to learn, but it pays off. It is more trustable. Often testing the functions is much easier, or not even needed. Exceptions are no longer a problem, because they do not exist. This might sound impossible, but you will understand it once you try it.
Both
Some languages can use both techniques. Object oriented is more common, but that does not make it better. It is often done badly. Languages like C# introduce a few functional techniques like LINQ.
The following video can be a good introduction on why someone would want to do functional programming, and how it differs.
Design patterns
A bit of code structure can be helpful to navigate and understand code. But it does not hold a candle against experience. Experience will teach you your own patterns, and which pattern you should use in which situation.
Many "patterns" and "concepts" are a bad joke. They solve the easy problem, and throw the hard problem over the fence. Guarding code against inexperienced developers is not great. People who aren't disciplined enough will screw things up with or without design flexibility. Improve them or remove them. Patterns can give you benefits, but many of them are overrated. Often they make things more complex.
Focusing too much on design patterns can lead to an anti-pattern called "analysis paralysis". Analysis paralysis is when a project is stuck in the analysis phase of development. There really are buzzwords for everything. A lot of design patterns cost more energy and time than what you get out of it.
The majority of design patterns only exist in object oriented programming. Functional programming does have mathematical patterns, which could be arguably called design patterns too. Many problems which some design patterns try to solve just don't exist in functional programming.
Methodologies
Methodologies are never "perfect". It is not bad to use one, but we should be careful to not make it seem like rules. It are guidelines. Many people see these guidelines as hard rules, and try to follow those rules to the details. It can waste more time instead of getting things done. Design patterns are guilty of that same problem.
Examples of problems with methodologies
TDD
Article: Problems with TDD - dalke scientific
The above link is old, but it does contain some interesting problems with TDD. There are things which you can't solve with TDD alone. Take for example a shopping website with coupons. People can try to add as many coupons, so that they get things for free. This is probably something which you don't want.
It is very possible that you don't reach a fix for a problem by using TDD. Thinking like a user which tries to cause harm can help to make your program more secure. This is often not needed in TDD. Good manual testing is often a good idea and can prevent such problems. TDD can help, but never trust methodologies completely. They are not perfect.
Agile
The word “agile” has become sloganized; meaningless at best, jingoist at worst. ... We have scads of vocal agile zealots—as per the definition that a zealot is one who redoubles their effort after they’ve forgotten their aim.
– Andy Hunt, one of the founders of The Agile Manifesto
And worst of all, agile methods themselves have not been agile. Now there is an irony for you.
– Andy Hunt, one of the founders of The Agile Manifesto
Article: The Failure of Agile
I don't agree with his opinion. Following something too strict can be a problem. It can cause fights over things which might not really matter. Different perspectives can be good.
Scrum
Certain people try to push Scrum to prevent operating in bubbles. Meaning that they want people to be able to do every job. Scrum does not always prevent working in bubbles. More often than not companies have very specific jobs which are not easy to learn for every new person in a team. Certain jobs are only possible by people who have worked in a company for a long time.
Scrum can result in having more meetings rather than doing actual work. Following it by the book is not worth it. Create your own methodology which works for your organization. Experiment, fail and learn.
Unix
The Unix philosophy tends to mean that one program should do only one thing, and do it well. This is idealistic, and relative. I could call Windows -- Unix. It does one thing, being an operating system. Many Unix programs are ugly hacks tied together.
The philosophy makes sense as a guideline, but many people go too far with it. Some unix programs do not function well without other unix programs, which cause that program to not do one thing well. Just to make it a bit more confusing, unix is also a trademark. It is a buzzword, and a cause of many long discussions.
A programming job
Doing programming as a job usually means that you can't choose what you create. Certain people claim that you can make a computer do everything you want, but you usually can't do that in a company. Besides that, it is an unrealistic, idealistic promise.
Companies can limit what you can learn and create by using policies. They can force you to use a specific programming language. The project which you have to work on can be something that you aren't interested in at all. You have to work for yourself if you don't want limitations. This is the case in many jobs.
It can be a fun job, but it depends on more than one factor. Dare to talk about the downsides when you say that it is a fun job. It isn't uncommon for programmers to work longer hours, because they want to finish a task. It can feel that you are in a "All Work No Play" cycle. To me programming doesn't feel that creative. It is rather logic focused.
Working all day on a project which does not interest you likely won't improve your quality of life. It differs from company to company, and depends on many factors. This includes the people you work with. It depends on the people and the culture.
Good things about programming
- There are almost always problems which you can try to fix.
- You are often able to get the opportunity to learn things.
- Many companies treat programmers really well.
- Working from home might be a cool thing, if you like that.
- It pays well, but you shouldn't do it for just that.
Keep in mind that every culture has problems or things which you don't like. This is just an opinion.
What others think
Xah Lee is a well-known GNU Emacs user. His Why Software Suck page contains his opinion about the programming culture.