Software Houses Do Research And Development
Software Houses Do Research And DevelopmentTo what extent do SoftwareHousesDoResearchAndDevelopment?
The one I work for at the moment doesn't do any. Any investigation into new technologies or techniques has to be done within the context of a project, explicitly to meet the needs of, and paid for by, by a client. I'm trying to challenge this. During a discussion with my line manager about this there was an illuminating exchange (condensed/WikiNameified?):
Me: We should do some R and D. Him: There's no budget. Me: So how do we remain competitive, if we're behind the curve all the time? Him: Good question, Me: It's not like the cost of R and D has crippled SunMicrosystems, or InternationalBusinessMachines or... Him: But we don't want to be like those companies, they are "cool" and we don't want to be cool. Me: Well, it might be nice now and again.I realised two things:
They do it on-the-fly in every product they put out. JIT invention. Quite cost-effective. Most R&D programs produce nothing.
Would that be at all the same as writing bids when you have no idea what you are talking about, then scouring the web for papers to rip off?
While it may be that the outcomes of most R+D programmes are not useful, the process of doing the investigation is. -- KeithBraithwaite
Some of the larger companies I have dealt with have a department called something like 'Advanced Technology division' (CMG in London springs to mind, and I think Logica have the same sort of thing.) They investigate new technologies and have experts in existing ones (e.g. they'll have a couple of red-hot Oracle DBAs etc.) They usually act as a central resource and get involved in writing bids and helping out in development. I don't believe that they actually do much development, beyond effective keeping their hands in. They may not produce much that is new technology, but they keep track of what others are doing. -- SimonSmith
Yes, both CMG and Logica do this, and they are supposedly the companies that my employer are competing with, hence my concern.
The way it frequently works here in the valley is that there is no R & D budget, but there are (1) small contracts which you don't expect to make much money on (which involve something a little closer to the bleeding edge) and (2) professional training courses and conferences (which, it is alleged, will acquaint you with newer technologies). And, of course, there are the ubiquitous developer's SIGs (talks, in the evening, by developers and for developers on softwareish topics).
The real upshot of this is that training / keeping up, for service oriented companies, is mostly up to the employees. Which leads to a gradual decay in the currency of people's skillsets (one reason for SoftwareAgeism?).
Product oriented companies, ones which aren't startups, don't seem much different. What seems to happen, among the people I know at least, is sort of a punctuated learning thing: Every three or four years, someone will look around, realize her skills are becoming obsolete, and make a concerted 6 month effort to get up to speed. This is often accompanied by a job change :-)
Then, another 3 or 4 years will go by.
A side note: being cool is great fun. I'm fairly certain that the work I've done recently on XML and RDF is all for naught. But, dammit, it's nice to hang around and actively participate in the formation of a new standard!
You have to know how to look for opportunities and take them when they arise.
For example, on a recent project, our customers were killing us with constantly changing requirements for the format, location, and layout of fields on screens. (Not changes in data needed, just formatting.) It was clear to everyone that we needed a more dynamic run-time data-driven mechanism for displaying screen data.
Another example:
Noticing that project leaders had tried, several times, to patch together ad-hoc Unix scripts to watch for files FTPd between systems, perform processes, write "confirmation" files, etc...
I said "Wait: What we're really doing here is making a sloppy ad-hoc attempt at building our own middle-tier / business-tier of a 3-tier system. We need to put away our 'monolithic server' and 'fat client / 2-tier' assumptions of previous systems, and find a reasonable infrastructure, like COM, CORBA (or even just sockets!) that we can live with. We're making a 3-tier system, like it or not, so let's think about doing it right."
-- JeffGrigg
Jeff, presumably when you suggested XML or CORBA you had already played with those technologies to some extent? It's that kind of opportunity to keep skills up-to-date (as Simon mentions above) that I'm asking about -- KeithBraithwaite
I just say, it might help our project. I'll take some time to explore XML or CORBA to see if it fits the bill. This works better if you don't have to account for how you spend every hour.
The rule at JeraDesign? is that you're supposed to spend 4 hours a week on "play time" -- working on something not directly related to any current deliverables. (I swiped this idea from TomDeMarco and TimothyLister's book PeopleWare.) Recent "play time" tasks for me have included: play with VisualAge for Java, play with JavaUnit, and play with Palm VII PQAs.
JeraDesign? also values continuing education and professional growth enough to have just sent its entire staff to XpImmersionTwo. :-) -- JohnBrewer
One strategy is to mine your turnover rate for new ideas. Since the payroll is in constant flux in software (10-20% turnover rates are common), you get a lot of people who have worked on different projects. They will have R&D experience you can get almost ForFree. I wonder if this strategy is really some sort of pyramid scheme. -- SunirShah
It is an example of how the MeltingPot pattern applies to software companies.
At UrbanCode, we also use the "play time" concept. In addition to that, we try to hold developer meetings about every two weeks or so. We use the developer meetings to share recently acquired knowledge and set a direction for future "explorations". For example, a while back we wanted to develop a standard approach to logging within our projects. We discussed this during a developer meeting and some developers threw out ideas such as Log4J, the JSR, etc. We then decided as a team that we need to look at this topic in more detail and some developers volunteered to spend some more concentrated time on the topic. After more investigation, the volunteers presented their findings during the next developer meeting and as a result we decided to standardize on Log4J.
Our experience has been that providing an effective means for sharing knowledge (leading edge knowledge) is just as important as acquiring it in the first place. -- MaciejZawadzki
EditText of this page
(last edited June 20, 2012)
or FindPage with title or text search