Every morning, medical doctors get together at a hospital ward to discuss the status of their patients, led by the ward boss, who happens to be another doctor.
Each doctor explains the medical conditions of his patience, what drugs he is administering, what exams he has ordered and performed, and what the prognosis is. The boss may suggest changing the exams and/or the drugs he is using, in case he feels that the doctor's approach is not conducent. Furthermore, he can suggest a new drug, new alternatives, and offer an experienced word on how previous patients with similar symptoms were treated.
Now, outside of the medical world... and back to our software development world... we have Agile Project Managers, who for the most part have never seen or written a single line of code. Yet they conduct a development team. How can that happen?
This is why I think they are by far the biggest waste of company's money. Somehow companies believe that anyone having taken a "Management" course can take the lead on a software shop. This is how we have people with absolutely no training in computers running software teams. The result, of course, is nothing but disaster.
These pseudo-managers, lacking the knowledge to appropriately run the show, have no choice but to rely on a developer to make the decisions they can't make. Such developer can easily see the opportunity to grow in power, eventually becoming influential on the manager's decisions, and the de-facto leader. Other developers in turn realize of the potential of becoming good friends with those protégé developers, to grasp any power this friendship can provide them. Eventually the whole development team becomes a fraternity, where a few developers end up running the show, project managers become just email-proxies (sending/receiving emails all day and that's it), and the whole company hierarchy is distorted.
So, "Agile Project Managers", if you don't have any background in Computer Sciences, a good 10 years of experience as a software developer using a variety of architectures and languages, please have some dignity and resign. I know there is quick easy money on reading a few Agile books, attending some PM conferences, and portraying yourself as a Manager... but the result is complete disaster for a Software team.
Wednesday, 14 August 2013
Monday, 12 August 2013
How software developers rip off their employers
Every now and then I stop my daily work as a programmer to look around and see why we do things the way we do them, and most importantly, how things have evolved in my 15 years of software development experience.
I must say that I come from an old school of programming, where performance, accuracy and a high dose of pragmatism were key to success (and to keep your job too).
In today's hot software development market, many people with little expertise saw the opportunity to make good cash easily.
Let's see what developers do to hide their lack of experience:
- Using ORM's
Not so long ago, software had to be fast, performant, and easy to use. This required very solid knowledge on writing database SQL, when to create and use indices, and database structures.
I must say that SQL is a very hard skill to master, and it doesn't come easy. It takes years of experience to write well performant SQL.
Many developers now a days don't even know how to write basic queries. This is why ORM's are in so much use. Even though this mappers's performance can not even be compared to straight SQL, developers refuse to go back to the origins of writing queries. The argument that developers make is that ORM's give you the ability to forget about the persistence layer. But, do you know of many systems that don't store any data? Not many.. So, developers, software includes persistence and data... deal with it. Stop ripping off your employers.
- Using Test Driven Development
In the times were applications had no unit, integration or automated acceptance tests, developers were forced to learn the code before they could make a change. That means, spending time learning the system, how each piece interacts with each other before they can make a change, and most importantly, what all developers hate: reading someone else's code.
Now, developers rely solely on pre-existing tests to do their work. If no tests are written, developers simply throw the towel and force companies to spend time and money re-writing the system.
It's amazing how developers were able to work 20 years ago with no tests, but now they seem impaired to do it.
Another observation on TDD is that it's used as a good way to cover people's asses.. in case an application fails, a developer simple responds with "all my tests passed".
Needless to say, TDD is big load of BS. Everything takes 3 times as long, since for every new feature you have to:
- Change the existing code
- Fix the broken tests caused by the new feature
- Write new tests to cover the new functionality.
In the last 3 years that my company started to use TDD, it only served me to realize that I was unknowingly breaking existing code 3 times. For all the other times that a test breaks it's because I am intentionally changing the code. Seems like the theory that it would serve as a safety net is far from being real.
- Using unproven technology
All developers love experimenting with new technologies. That's a fact. We think we are smart, a kind on its own, higher-than-average brained beings on the planet who are entitled to leave something for posterity, and if that "something" implies recognition from other colleagues, you can't ask for anything better. We don't want to do menial work and simply get things done for your boss to take pride of, right? We want to set the stage.. and if that comes at the expense of delaying projects, that's something companies will have to live with.
I could have an endless list of frameworks, databases and applications that are so amateur and flaky, but developers still insist using them, when they could use more traditional tools that are already proven, that have been in the market for decades. and do exactly the same.
Using unproven technology will inevitably lead to project delays, unforeseen events, bigger costs, code re-writes... but, it might lead to some new knowledge to add to our resume... and that's all that developers care about.
Agile Project Managers deserve a whole new article... they are by far the ultimate waste for company's money. Read it here
To summarize, in a market where developers are in high demand, we have managed to use our employers as our guinea pigs. Of course, this will have to change when market conditions change, and the power goes back to who are paying our salaries.
I must say that I come from an old school of programming, where performance, accuracy and a high dose of pragmatism were key to success (and to keep your job too).
In today's hot software development market, many people with little expertise saw the opportunity to make good cash easily.
Let's see what developers do to hide their lack of experience:
- Using ORM's
Not so long ago, software had to be fast, performant, and easy to use. This required very solid knowledge on writing database SQL, when to create and use indices, and database structures.
I must say that SQL is a very hard skill to master, and it doesn't come easy. It takes years of experience to write well performant SQL.
Many developers now a days don't even know how to write basic queries. This is why ORM's are in so much use. Even though this mappers's performance can not even be compared to straight SQL, developers refuse to go back to the origins of writing queries. The argument that developers make is that ORM's give you the ability to forget about the persistence layer. But, do you know of many systems that don't store any data? Not many.. So, developers, software includes persistence and data... deal with it. Stop ripping off your employers.
- Using Test Driven Development
In the times were applications had no unit, integration or automated acceptance tests, developers were forced to learn the code before they could make a change. That means, spending time learning the system, how each piece interacts with each other before they can make a change, and most importantly, what all developers hate: reading someone else's code.
Now, developers rely solely on pre-existing tests to do their work. If no tests are written, developers simply throw the towel and force companies to spend time and money re-writing the system.
It's amazing how developers were able to work 20 years ago with no tests, but now they seem impaired to do it.
Another observation on TDD is that it's used as a good way to cover people's asses.. in case an application fails, a developer simple responds with "all my tests passed".
Needless to say, TDD is big load of BS. Everything takes 3 times as long, since for every new feature you have to:
- Change the existing code
- Fix the broken tests caused by the new feature
- Write new tests to cover the new functionality.
In the last 3 years that my company started to use TDD, it only served me to realize that I was unknowingly breaking existing code 3 times. For all the other times that a test breaks it's because I am intentionally changing the code. Seems like the theory that it would serve as a safety net is far from being real.
- Using unproven technology
All developers love experimenting with new technologies. That's a fact. We think we are smart, a kind on its own, higher-than-average brained beings on the planet who are entitled to leave something for posterity, and if that "something" implies recognition from other colleagues, you can't ask for anything better. We don't want to do menial work and simply get things done for your boss to take pride of, right? We want to set the stage.. and if that comes at the expense of delaying projects, that's something companies will have to live with.
I could have an endless list of frameworks, databases and applications that are so amateur and flaky, but developers still insist using them, when they could use more traditional tools that are already proven, that have been in the market for decades. and do exactly the same.
Using unproven technology will inevitably lead to project delays, unforeseen events, bigger costs, code re-writes... but, it might lead to some new knowledge to add to our resume... and that's all that developers care about.
Agile Project Managers deserve a whole new article... they are by far the ultimate waste for company's money. Read it here
To summarize, in a market where developers are in high demand, we have managed to use our employers as our guinea pigs. Of course, this will have to change when market conditions change, and the power goes back to who are paying our salaries.
Subscribe to:
Comments (Atom)