It's been a while

 I don't put the effort into this that I thought I would.  Regardless, I thought I would just say "out loud" that I think Elix...

January 18, 2014

Your company might be making mistakes if...

I recently found this article about mistakes that companies make with development.  In it, they list out these mistakes:

  1. Paying poorly
  2. Providing inadequate equipment
  3. Going into technical debt
  4. Rolling your own when good alternatives exist
  5. Not providing dedicated project management
  6. Using developers for non-developer tasks
  7. No learning for learning's sake
  8. Offshoring Development
I have worked at firms that have committed all of these, except #1.

So, should you leave to get improvements in any of these?  That, of course, is up to you.  I only really see two options:

  1. Be an agent of change
  2. Leave
Being an agent of change is very difficult in my experience.  I wish I had some success stories to share with you, but I don't.

Here's one example:  I have thus far unsuccessfully, argued for a group of developers to write unit tests.

You'd think that this would be easy, because isn't unit testing at this stage a given best practice?  You'd think so, yet, I see many of the excuses used.  In fact, the "Word has been given" that we shall not write them at all on one project, and we may not commit them to the repository with the rest of the source on any other project.

So, I can write unit tests, somebody else will break them and be completely clueless about it.

I have tried to educate, but so far, it has meant nothing.  If people don't want to change, it is unlikely they will.

As for the other points in that list.

#2 and #3 affect you every day when you start working.  Does your PC work?  Does the code stink?  Both of those suck to deal with every single day you work.  Incurring technical debt is natural, but if you can never go back and fix it, then that load of debt keeps growing and bogs down everything you do.  Projects stall, or take longer than expected.  Bugs are very difficult to fix, as well.

The worst thing is that without doing #7, people may not even know they are incurring more technical debt.  Unaware of unit testing?  Writing huge monolithic procedures?

That's debt that you may never get out from under and you may not even know it.

No comments:

Post a Comment