The importance of trusting your developers

It’s not the first time, and sadly it won’t be the last, that I’ve had to work behind a paranoid firewall. I can understand an enterprise concern with regular employees surfing the web unrestrained (I’ve seen computers rendered almost useless from large infestations of virus, malware and other things I’d rather not mention). But developers? Please...

At my last gig there was no access to any cloud storage service. None? Really? That’s what they thought, any geek could find a way to export data, even with USB ports disabled! But restricting cloud storage makes sense, you limit potentially dangerous traffic which you must monitor.

But restricting access to social networks, blogs, etc? What year is this? Don’t these people know we live in an ever-changing environment? What are they trying to accomplish with these restrictions? Maybe this? Or this? I’m confused...

In order to keep our knowledge sharp we need to access developer communities, blogs, forums, custom libraries, etc... We need to interact with other developers so that we can learn from them. That includes chatting with them, sending them emails with code snippets, hearing their issues and trying to resolve them...

My last blog post is a perfect example, I finished it with a question: “How do you mock all dependencies of a unit under test without dependency injection?” I thought there was no answer but, after no more than 3 hours of being published, +Maarten Seghers gave me a great solution to my problem.

Had I been able to reach the hive-mind before, my productivity would have skyrocketed. But no, I was behind a paranoid firewall. Let me finish with another question: If an employer doesn’t trust their IT experts, why did it hire them in the first place?

The importance of SOLID principles

I don't know why it’s not a common practice in my country to apply engineering principles to software development. It's shocking that practically every project manager and programmer I've met thinks that engineering principles are merely an academic matter and, in real life, it’s more important to sprint to deadlines than to waste resources designing the product and applying good development practices. What baffles me is that all those projects I've found where the team didn't follow such principles had a lot of trouble meeting deadlines because adding features became increasingly harder without having to break something already built in. And those involved never even realized why this was. It’s really simple, big projects are more like a marathon than a 100-metre dash, so you can’t be sprinting all the time without losing your breath and failing to keep the required pace in order to arrive on time.

For example, on my most recent project, the team lost their way and eventually dropped almost every good development practice they had started with. When I arrived during the third year of the project, I tried, as always, to produce quality code despite the project manager’s lack of interest on that matter. I managed to DRY the code, introduce test-driven development, create integration tests and came close to applying every single one of the SOLID principles to all my work... all except the last letter (yes, my code was only SOLI). Due the design of the factories that we used I wasn't able to comply with the dependency injection principle. Ok, it didn't matter... Actually it was a pretty good achievement to have improved the product quality, even when that wasn’t my boss’ primary concern, while all my deadlines were being met... Attaboy!

Everything was going smoothly, but when the number of my automatic tests started to grow I started foreseeing some problems: a good portion of my tests overlapped, so the execution time was not optimal for their code coverage; and almost all of them modified the database’s content which caused a deterioration of performance and readability because I had to insert data for the tests and clean up after their execution.

Solution? Mock all DAOs and other dependencies in order to improve the tests’ readability and performance. But how do you mock all dependencies of a unit under test without dependency injection?

Attaboy! :(