I work for a small company that has about 25-30 employees. We make software for the hydraulics industry and most of our employees are mechanical engineers who are self-taught programmers including me. One difference that I find between myself and other employees is their lack of passion for software and their will to learn more about software. This attitude is responsible for our caveman-like development practices. Until one year ago we didn't even use any versioning system and still we don't use any automatic build system, code reviews, bug tracking system or any other beneficial practices that are used in the software industry. The result of all this has been products that are horribly inadequate and fall way short of customer expectations. I want to change all this but being on the lower rungs of the organization hierarchy I find it difficult to persuade my seniors. What strategy should I use to improve the situation. Have you ever found yourself in such a situation? What did you do?
You could encourage management to invest in a small library of books including titles like Code Complete for developers, or Peopleware for project managers, and ask them to incentivise staff to read them
You could also try and organise training for staff.
Another option would be to set up a sandbox where new technologies could be tried and tested for use, i.e. set up subversion on a virtual LAN, etc.
When in that situation, the only thing you can do is lead by example and introduce changes slowly. Take on a small project and use some modern agile techniques, bring it in on time and then shout about it to everyone else.
When your projects are succeeding and theirs are slipping, they either start to take notice, then take on board the new ideas, or management will demand to know why.
If you are not senior enough to manage a whole project, use such techniques on the parts of the projects you work on. The battle will be longer and harder, but with determination you can still get there.
I'm only going to talk about the bug tracking system part, because I have personally succeeded in getting others to use a bug tracking system when they weren't using one before. Here's the recipe:
Pick an easy to use web-based bug tracker and install it on your box. If you are a windows shop, then my own BugTracker.NET is a good choice, but the key is, the bug tracker should have no required fields beyond just a one line description. It should be as painless as possible for somebody to enter a bug. If it's customizable, REMOVE fields from the form so as not to intimidate.
Then, you go around personally, face to face, and set up a web favorite/shortcut to your installation on each of your co-workers desktops. You have them create one test bug while you are there.
Make it fun. Give the adopters food rewards.
If I've learned nothing else, it's that a company always follows the direction of the leader. If there is management support for something then it will happen, and conversely if there is no management support it will not.
I've fought many uphill battles for change against a management team that was more interested in other things (profit, LoC/day) than actual sane development practices.
If you have management support, then it is all about leadership of the senior staff. If they do it, everyone else will too. If they don't, they won't. It really is that simple.
Some of the things that you talk about can't be done without systemic changes. One thing that you can do on your own, if you aren't already, is start doing systematic unit and integration testing. Write suites of unit tests / integration tests that allow you to detect errors before they ship. Write more tests as bugs are discovered that, first, demonstrate the bug, then once the code is fixed, show that the bug is gone. Run these tests (at least unit tests) before you check code into your repository so that you're confident that you aren't introducing errors into the accepted code base.
Your code will start to improve and you'll gain credibility with your peers and management that you know how good code is written. This is the most effective way I know to affect how others write software. Demonstrate before you pontificate.
Given you colleagues disinterest I can only see you being able to take a two phase approach.
Firstly, as pointed out several times above, start doing the right thing yourself. For the most part, this list is basically a big chunk of The Joel Test a.k.a. 12 Steps to Better Code.
- use a version control system.
- use a bug tracking system.
- writing unit tests.
- writing system tests.
- running regression tests as you add new functionality to confirm you haven't broken anything that was workin previously.
- maybe use TDD?
- start keping fragments of code for reuse, e.g. Perl fragments for timestamps, or logging messages, etc.
- start getting people to peer review your code.
- start a development wiki where people can keep up to date internal documentation
Secondly, this will make you stand out from the pack.
So either management notices and asks the reasons why? This could lead to a mandated introduction of the various processes.
Or, your colleagues notice and ask why which leads to a viral introduction of these processes.
Either way, this is going to be a long process.
I'd suggest getting a couple of excellent books on the development process, e.g. The Pragmatic Programmer (sanitised Amazon link) or Code Complete (sanitised Amazon link).
HTH.
cheers,
Rob
I, myself, am working at university level in a small team of 20 people, in numerical modeling, mostly mechanical, civil and environmental engineers. I'm almost exactly in your case. All I can say is that if the leaders don't tell the others to follow best practices, then you'll have a very hard time. I personally have kind of given up.
I can speak for my personal experience. We use a versioning system (sourcesafe) which sucks. But no one wants to change to a more modern version. No bug tracking. No unit testing. No development virtual machine sandbox.
I tried to install a wiki, mediawiki. It worked quite well, at least it worked for me, and I store there all my knowledge. When my colleagues ask me for some advice, if it's in the wiki, I always invite them to read it and improve it. Most of the time, only 3 or 4 individuals update it (a small percentage).
I guess a wiki can help. You can also start writing an internal blog about your breakthroughs, achievements and best practices. Eventually some elements will become your readers, but beware of the jealous...
As another poster or two have said - preaching will not really get you anywhere. You have to just stick to your guns and do development the right way. Lead by example and keep people informed (but don't be overbearing) about what you do and WHY you do it.
Keep a small/simple process document and show it to people if they ask about it, but don't force anything down people's throats. It doesn't work and turns people off.
Support others who may be trying to do the right thing - it is hard to buck the trend so support those developers who need some help with saying no to management when for example they are told to check something in that wasn't tested, etc.
Again, this is based on my experience - I tried to change a group I was in at a large software company, but got nowhere until I was put in charge of a group and we just quietly did things our way with great success and then eventually people started asking us what we were doing to get the success...