Common Sense Driven Development

Nowadays every day or week we’ll getting new framework or tool everyone is hyped about. is a great example of trolling JS people about that. Development is a lot about this new and exciting technologies but day to day life is not as simple as using the cutting edge, shiny things.

The double edged sword of Cargo Cults

For the definition I’ll fall back to good old Wikipedia:

(…) attempt to emulate more successful development houses, either by slavishly following a software development process without understanding the reasoning behind it, or by attempting to emulate a commitment-oriented development approach (in which software developers devote large amounts of time and energy toward seeing their projects succeed) by mandating the long hours and unpaid overtime, when in successful companies these are side-effects of high motivation and not requirements.

As managements issues are important, I’d like to focus more on first part of the definition.

There are from time to time new tools and practices released and world is getting crazy. I’d say React.js is one of them. Other may be Netflix Cloud tooling or good old Docker and Kubernetes on the Dev/Ops side.

And don’t get me wrong, I like them all. The difference between what you can use and what to use to make your project successful. It’s context of making decision being more important than decision itself.

Having technology solving your problem is great but you may fail because of very steep learning curve. Tool may be not supported in few months or new version will be released and you’ll have nice and shiny legacy code even before release.

What to look for

  1. Make sure you’re not trying to use the same hammer for every nail – there Is a lot of technologies and some are better in some tasks than other. Like PHP and multithreading or long running processes. You don’t want to do this to yourself. Maybe better solution will be to get people to learn a bit of Java of node.js to make this subsystem?
  2. Support – is the library you want to use “mainstream” enough for you to use it and be sure it will still exist in few years. From other hand ask yourself if you really need to use library for some very simple functionality you can write in about 20 seconds.
  3. Learning curve – Check with your team new solution can be understood and implemented correct way. As an example I can take CQRS and Event Sourcing, which are quite complicated topics and used mostly in enterprise environments. Anyway people often think it’s silver bullet for their problems and going through with it. Often they are right but as it needs time for people to learn about it’s problems it’s better to take middle ground and tart with just emitting events before switching to ultimate solution.
  4. Look at yourself first – There is a lot of companies and a lot of ideas. None of them is a silver bullet. There are also old, “bad” ideas. Like monolith. And those bad ideas are good in some cases. Like when you have quite big application to write in small team.
  5. Take authorities with grain of salt – aka Cargo Cult of the person. It happens when opinion of one person becomes opinion of the community. You know examples of that from global politics. And I’m not saying those people are wrong. They are just preaching one solution which they like. And it doesn’t really matter if it’s correct solution of programatically correct. Their acolytes will quote them in every meeting. Argument of need and correctness of the solution will be pushed back because of argument of well known person having opinion.

There is only one correct answer – it depends

I’d assume there is as many styles of coding and tools as developers in the industry. Some are better than others. Some are evolving and getting better and better. Some are legacy at the idea level but still generating revenue for the company.

Bottom line is that there is no single answer to a problem. Context of the problem changes everything and I think it’s the most important thing to look at when making technical and process decisions. And then choose which hyped tech use in the next project.

Prototyping vs Maintenance

Last two weeks I was thinking a lot about whole process where I have a client on one side and a working application on the other. Fist big thing is in the title of this post. Too often we prototyping instead of thinking what happens next.

Of course it’s human factor but when I’m thinking about reason why it’s happening I say modern frameworks. Rails, Symfony, Cake. Whole “MVC way of development” which is not bad but it’s also not everything. Anyway when you check tutorials for them it looks like that. It’s also an issue with dynamic languages. They are used for fast projects and it’s quite hard to force management to think about trivial things like architecture of the new application. Fast language doesn’t mean that we should code without proper preparation.

Sooner or later we have huge codebase and we are no longer prototyping. We maintain current code and create new features in current system. And we are doomed, because we have a lot of procedures in controllers, procedures in model and some in views. Even if there are some tests they are useless when everything is done in one place and cannot be pulled outside. One common thing which I noticed lately is creating pagination objects. OK, pagination is a service in Symfony 2 but most of the time we have pagination in application and in control panel. Why the hell we are copy/paste this code when we can outsource it and put different HTML on result? When we take a look on time most of it we spent on maintenance. So why we are not investing on the beginning in good and clear code?

Because it’s hard on the beginning and it takes time to create good object graph. Design patterns are moderate easy but they need, like everything else, practice to work smooth. It’s also more code. Simple triple if can take interface, chaining class and three implementations. Instead of few lines we have few files. Is it easier way? Not yet. It pays off in few days when another if is needed and all whets needed is one class with specific responsibility and this single responsibility rule is one of factors of maintainable code.

It’s also very important when new person join the project. Simple change in method which is returning bool after 5 lines of code is easy and safe for rest of code. It’s also very testable. By the way these day I realized why I didn’t liked TDD. Testing big procedure on framework level is a waste of time. What is the idea after testing controller with 20+ lines of code? Everything inside should be tested on lower level. Controller only takes what is needed for user in view and forwards data to template. Nothing interesting. Failed test is also worthless. There is plenty of things which could failed. Let’s think about failed test of dashboard. It gathers data from all around the system and renders some graphs and tables. If test failed it can be anything from malformed HTML markup to data inconsistency id database. Good luck with finding it in less than 10 minutes.

And time is the most precious thing in our job. We get payed for getting work done in time. So please stop wasting it. Think before, not after. It’s common knowledge so use it with your job.