I have been pondering on this for a while and need to get some feedbacks from fellow developers.<p>Here is the scenario:<p>I am a developer documenting what I work on (apis, tools, etc) to. However, my colleagues don't. This have been driving me nuts but I cannot change them (I tried).<p>I also like to improve existing tools (build system/ code base). However, my colleagues don't.<p>Here is what every developer faces every day:
- No automated build (e.g.: Continuous Integration Server)
- Released archived as emails instead of FTP/Nexus like software.
- Developer builds production releases on their dev machines.
- Undocumented APIs/build system
- No automated test
- No clear roadmap
- No code review
- New developers are hired without going through any technical interviews nor have background
or experience required (programming language, software dev lifecycle, mindset).<p>The business was not doing well until recently which explains why all those things creeped up (although IMHO, automated build and unit test should be done anyway).<p>Now, the business is doing well, I managed to develop an automated build system after a year or so battling with management and reworking tools to make it happen.<p>New hires are coming in but I feel those processes aren't really used/sought by other developers. Some management folks seems to care about the issue but don't see the need as much as I do; a strong, well structured yet flexible software dev process is a very valuable asset for any company and should be respected fully.<p>No other developers (about 20) raised any concerns about the current software dev process, only me.<p>a) Am I too impatient since things are slowly changing ?
b) Am I too process oriented ? This is a 5+ year old startup.
c) Am I the problem ?
d) Is this software shop not a good place to work for and improve one's skills set ?
e) Should I just suck it up ? That's the startup world.<p>I really appreciate your feedbacks.
Have you read the Pragmatic Programmer? They talk about how to handle a situation like this. From what I remember it said to build a pocket of excellence in your dev workspace first, and then expose everyone else to it.<p>Set up the CI/build server on your machine, have it email everyone when the build fails. They will see the use of the tool then, and when the team accepts it they will hopefully get an official server to host it on.<p>Write tests for your code, and when other devs work with you on issues, or break things, write tests and send to them "Hey, i wrote this test that shows the code you wrote is failing, can you make it pass?" Also ask others to make unit tests. You will have to write the bulk of tests. You probably know which others on the team are open to writing tests and working with you on the pocket of excellence. Get them involved first, and then the idea will spread. A good idea would be buy them copies of Pragmatic Programmer too.<p>No, you aren't process oriented. A software team that doesn't at least like the idea of automated builds, and tests is crazy. As far as if it's a good place to work and improve one's skills? That depends. In some teams you might never get them to adopt the pocket of excellence. If you are working in a place like that, then it's probably not a good place to work. But if you have a shot at converting them by just doing it on your own first, then it would be a great opportunity to get experience with setting up these aspects of a software shop. And you can put that on your resume, blog about it, etc. In that case it would be a great experience.
Personally I'd probably leave. I think there is a point where its healthy to try to change the system but it sounds like you are fighting a current that is too strong to encourage the way you want to work.<p>I believe you when you say your efforts are needed - the problem is management very frequently has a hard time being able to understand that there is an upfront cost that will eventually pay off. They are looking at spreadsheets and just want to see that profit column keep on going up - you essentially are proposing that the profit column should go down a bit (development costs) with the promise that it will eventually go up much faster.<p>I've found that software companies either qet the necessity of quality/process or don't (also some types of businesses do not really need much software quality). Most of the time this is determined by if they have technical people in the leadership ranks or not. By the hiring practices you listed Im guessing they don't get how software quality and process impacts the bottom line.<p>My pessimistic view is that very little will change with the exception of burning yourself out - sorry for the dire prediction Ive just been there myself.
Don't worry about the process. Worry about the outcome of the process. Is the site always down? Do you fail to ship? If so then you need to fix things. Otherwise just let people work the way that lets them be most productive.<p>For instance, I'm not a fan of unit testing. I find that 99% of the time when my tests fail, the failure is the test itself, not he code. WHen I'm forced to write uni tests for everything, it slows me down greatly. I prefer to keep my code clean and readable, instead of focusing on 100% code coverage. The same principle applies to CI and other such "processes", in my experience. But thats just me, everyone works their own way.
I recently quit my job for pretty much the same reasons. (I even created an auto build system, too... weird.) I actually faced a professional development dilemma: No forward progress. In an environment like that, where you have 20+ other people who don't care, aren't paying attention, just hack things together... you're not going to make forward progress (professionally, and the business will eventually be burdened with wanted growth and a messy code base, or something will break big-time and cause major loss of revenue). They are and they will continue to be stuck in the muck until someone closer to the top most likely runs into a very hard decision, or looses a great deal of money and has to face up to the reality of how they're building their business. I recommend moving on. There's some positive to be said for being pragmatic (sometimes you just have to hack it). However, if this culture is persistent, it's a BAD culture, especially if they hire inexperienced / unqualified people, and start teaching them these habits / traits (bad ju-ju for everyone, the entire development world, when places operate like this).
"Now, the business is doing well"<p>That is what matters to the decision makers in any business at the end of the day. So if that is the case, you might not be able to convince the management. Sure, your points are valid and I have the same frustration at work many times but understand that management doesn't care about proper unit testing etc. unless it impacts the business. As someone else pointed out, if you have critical production bugs frequently causing loss (specifically monetary), then you have a solid case to argue to change the process.<p>Not to say that you should just suck it up. I think it is worth to try and do things the best way but just keep in mind that you should not expect management to just do it because it is the right way to do it. So keep expectations low but keep trying as well.
Lead by doing. Show what you're doing and why, and get others to support your vision. Then it may be easier to get others do tackle some of the challenges with you.