Musings from the Trenches

Tags:

By Fabrice Retkowsky

Tales of the gap between research and industry abound. Having jumped this gap by completing a PhD within the PPIG area and then joining a web service company, I take this new column as a chance to put together some thoughts on the issue.

While researching on the "Psychology of Java Software Reuse" at Sussex University, it became quite common to hear or read researchers (both inside and outside of PPIG) complain of the lack of communication with the industry. Now that I work for Runtime Collective, where we create web sites such as www.infoconomy.com, I realise how this communication could happen if only both sides were interested in the same issues.

What challenges a company such as Runtime is diversity: diversity of skills, people and technologies brings innovation, synergy and motivation, but also raises problems:

1. Diversity of programmers

Programmers have various skills: some will be good at understanding code, others at quickly fixing bugs, they may have more experience with such or such language. But more than that, they may have programming styles: coders fancy getting their hands dirty and can browse and hack through huge programs easily, while developers will design and plan things carefully but program slowly, and enhancers will modify, correct, fix, improve the usability of a system, etc. Why is that so, can people change their style, how can different profiles work together?

For example, how can a "prototyper" (who likes the instant gratification of methodologies which let him get a basic system working quickly) work with a "planner" (who prefers careful preparing, designing, building and testing)?

And why are there such differences between programmers? Is it only a matter of experience, but then, what is really experience? Estimates of experience in the literature are plenty: number of years of programming, number of years of professional work, number of languages learnt, ... have all been used by experimenters to infer the elusive "experience" quantity. But what use is this quantity, when all that matters for a company like ours, is efficiency: how much time a programmer will need to implement such or such functionality, when will the new system be delivered, etc.

2. Diversity of "kinds" of programming

Most of the literature identifies and studies usual programming tasks such as understanding, designing, coding, and debugging. Yet all of these will be strongly influenced by the "kind" of programming used. Here at Runtime, within one same day a programmer can template some ADP web pages, then do some core implementation in Java, then configure a new system by editing some Tcl scripts, and finally draw out some OO relationship designs. These kinds of programming (templating, scripting, system design, coding) are very distinct in nature.

Obviously, programmers gain efficiency in each of these with practice, but some of them also seem to be naturally more skilled for one than for the others. This suggests that these programming kinds don't require the same skills, hence the same "thinking" (mental processes), and therefore that they cannot be represented by a unique model of programming.

Shouldn't there be a set of fundamentally different theories and models for each kind of programming, rather than one unique model of programming? Understandably most research has focused on proper analyse-design-code-test development, but at Runtime (and similar companies) most of the "programming" time is spent doing things like creating and modifying templates, installing new systems and reconfiguring them, maintaining and querying a web site's database, all of which hardly fall into the analyse-design-code-test category.

3. Diversity of working styles

Programmers have varying skills and behaviors. Furthermore, they don't work on their own. Programming takes place in project teams (small teams in Runtime's case, between 2 to 6 members). Team members don't just interact socially: they actually work together, and influences each other's programming. They share their knowledge, their understanding, their tasks, their expectations, and more than once clash on their opinions. Moreover, with programming techniques such as XP (extreme programming, see www.extremeprogramming.org), they code, debug, understand in pairs. This is a far cry from most empirical research where single programmers are asked to write a small piece of code on their own. How do all the interactions which occur during "programming" impact on it? How does it impact on separate tasks: design of OO models, querying of a database, templating of a new web page? How do programmers with different interaction styles (e.g. social versus independent) can cooperate?

More generally, and this is possibly getting outside of the boundaries of PPIG, Runtime staff diverge on the amount of structure they apply to their work: some display disciplined, ordered, formal work habits while others prefer less structured styles. The solution is obviously not to force everybody into the same mould: efficient staff is of utmost value - who cares about their idiosyncratic behavior as long as they are 5 or 10 times more efficient than others. But what can be done to reconcile each individual's preferred way of working in order to maximise the overall team efficiency? How can the sharing of information be maintained or optimised, and can various profiles work together, can rules be applied to non-structured styles, is it really worthwhile?

As I found out when writing my thesis on reuse, asking questions is easy - if only you can ask the right question. Reuse is, as much as I had expected, an important issue for the IT industry: if you can develop and deliver more quickly better software, then you can increase your margins, reduce your prices, etc. It also helps you, with time, build better systems which have the pooled functionality of individual projects. And the sine qua non to achieve this (far from purely cognitive issues such as program understanding, programmer's memory overloading, and so on) is to maintain compatibility between systems: if two systems are built on the same toolkit, but cannot co-exist on the same server, how can they be merged or at least work together? How can two distinct systems communicate together if they don't use similar interfaces? How will they communicate and work with external systems? A solution is to adopt a stable, open, standard development platform, and to adhere to standards such as XML, SOAP. Writing to a standard is an increasingly important part of the web industry - but I cannot remember any literature covering this.

Finally, I mentioned some of the languages we have to deal with: ADP, ASP, JSP for web page templating, Java and Tcl for core programming, Tcl again and Perl for scripting, SQL for data-model creation and database queries. We definitely don't use languages such as Prolog, Pop-11 or Fortran. It would be interesting to see research focus on the languages which we are actually using.

I hope these many questions will grab your attention and maybe kick-start some discussions on the PPIG mailing-list, in any case do not hesitate to email me directly!

Fabrice Retkowsky
fabrice@runtime-collective.com
www.runtime-collective.com