Eventually, software development will be done by software development companies. Some companies already get it, and they hire companies like ThoughtWorks to do development for them. The end result is a better product at a cheaper price.
Other companies that don't get it still do in house development. The problem with in house dev is that everyone involved on the project is overhead. Therefore, corners are cut, roles that are required are not filled, and quality suffers. Often many junior employees are hired because of cost concerns. The result of the cost "savings" is bad code, which costs quite a bit to maintain. Additionally, the turn over rate of the talented developers is higher because there is always a better opportunity around the corner. In the end, technology evolution kills the project and all the failures are swept under the carpet as version 2 is built in the latest technology.
A hybrid approach where a company like ThoughtWorks is brought in to work with the in house team can also work. Then, the maintenence can be done by some of the original developers. Also, the heuristics of the software development company can be transferred to the in house developers.
I've been seeing this trend for several years; however, since technology evolution hides the project failures, in house only companies fail to recognize the problem. The process will be slow, but software development companies will prevail, eventually.
Comment duplicated from my blog here...
ReplyDeleteSorry Jay, but I really disagree. There's nothing inherently wrong with the idea. The problems you cite are problems that any short sighted organisation will find when they're attempting to build software. I've worked for a couple of software houses and those I've worked for suffer from exactly the same problems described. Short sighted recruitment processes, cost cutting exercises, low quality code.
True, when you're working in-house these problems may be more common. The terms 'cost-centre' and 'profit-centre' are two that really cut to the bone.
However, I'm now working as an in-house developer with a team where the staff turn over is extremely low (around 10%), the team is built of very high calibre developers, morale is high, uptake on new technology is measured in relation to reasoned benefit, code quality is higher than I've ever seen before and customer satisfaction is through the roof.
We don't have any external people / consultants / software houses involved and I don't see any reason to have any.
In-house development isn't necessarily doomed to failure. Short sighted, cost driven organisations are the problem, and software houses are by no means immune to it.
Bob, working for a company you really like is great and I understand your desire to defend it. However, I stand by my statement as the rule, while your company is the exception.
ReplyDeleteSoftware houses with cost driven agendas will absolutely suffer the same fate as in house development.
Unfortunately, non software houses are doomed to fail because:
1. The best employees desire to continue learning. They will leave to work with the best in the business.
2. If your applications are high quality you won't have to rewrite them annually and you will run out of new work.
3. Strictly in house development teams can only learn from each other. Therefore, your solution selection aka toolbox is limited to the experience of few instead of many.
I think a company that is large enough it requires a in house development staff of 300 could be successful on it's own. However, I don't know any.
OK, I accept that on average a software house will produce a higher quality system than an in-house team. I definitely can't argue against the ability to produce tools. But then Cruise Control is open source isn't it…?
ReplyDeleteHowever, I'd say that the quality of most software projects is currently very low, especially those coming out of large houses (EDS anyone?).
And I still don't like the sweeping generalisation in statements like 'non software houses are doomed to fail'
To further defend the company I work for (well, it's irresistible isn't it)...
1 - The best employees desire to continue learning…
Agreed. Any company that does not encourage learning needs a severe examination of what they're doing.
2 - If your applications are high quality you won't have to rewrite them annually...
Agreed. But then the system we need tomorrow is not the same as the system we need today. High quality systems lead to ideas on other high quality systems. Whilst there may not be an infinite amount of work at any company, there's never just the one system. Not having to redevelop our current system means we can think about the next system...
3. Strictly in house development teams can only learn from each other.
Disagree. Anyone that's passionate about their job will mix with other people who do the same job elsewhere, with the same amount of passion. I've learnt a huge amount from people I have never and will likely never work with. And reading always helps too.
To cut a long story short (my opinion):
Good companies attract good employees
Bad companies attract bad employees.
Software houses have a number advantage over In-house development teams for both training and tools.
Both in-house teams and software houses can produce low quality software.
There are exceptional companies in both avenues. Thoughtworks is one, S-Three is another.
The in-house team isn't doomed to failure, it's just got to evolve in the same way as the software house.
Oh, in terms of numbers. We currently have 12 developers.
Bob, while I don't agree with you, I don't feel like the conversation merits much more discussion.
ReplyDeleteI think it's wonderful that you found an rose in the cement.
I still think you have the disadvantage of not being able to pair daily with the luminaries in the industry. However, you feel you mitigate the experience risk with research, and I applaud your (and your teams, hopefully) effort.
Additionally, you run the risk of being stuck doing maintenence work, but perhaps this isn't a concern of yours.
Also, with a team of only 12 there doesn't seem to be much opportunity for growth within. And, any turnover likely hurts more than if your team were larger. However, this is offset by the fact that you likely attract good new hire candidates because of the environment you offer. This is a small issue, just a note, not a point to further back my opinion.
While you "don't like the sweeping generalisation" statements, I love them. They spark thought provoking conversation.
Thanks for your opinions and good luck with the in house dev.
P.S. The fact that you read the TW blogs only shows that you enjoy learning from the best. Wouldn't pair programming with them be the next best thing? We'll expect your resume whenever you are ready. =)
Jay, you have some very good points. I've worked for enough in house dev teams that fell apart because of the exact reasons you state. I've also worked for software development houses that fell apart for much the same reasons.
ReplyDeleteI also strongly disagree that being in house limits your learning. A good programmer will look beyond the place in which they work for sources of information. I've never worked with Zend but I know much about the internals of PHP.
Sweeping generalisations are brilliant. Its ironic how narrow minded they make the generaliser sound though. Good job we can see through that though!
Well Jay, the blogs make good reading, yours included. I'll be keeping a eye open for your posts in the future...
ReplyDeleteIt was conversations with Thoughtworkers *sic* that first set me down the path of XP (and enlightenment?). Who knows, maybe you'll headhunt me yet :-)
Hi,
ReplyDeletei am doing a research on this topic (master thesis). Can you point me to scientific resources where i can find a bit more about non-software companies which do (still) have a software development team.
thanks in advance.
LV
Can you suggest other companies that share the same ethics/values of ThoughtWorks?
ReplyDeleteTotally in home growth groups can only understand from each other. Therefore, your remedy choice aka strategy is restricted to the encounter of few instead of many.
ReplyDelete