June 16, 2006

SpringOne day 2 keynote

Gregor Hohpe – Where did all my beautiful code go?

– Why is it that, even with a fantastically rich toolset, and the best and brightest developers, we still get crappy stupid code being written? (Gregor provided some examples from the google codebase)

– Its all about having a good representation of the business domain

– understand your domain

– choose your models

– choose a language to represent the model

– map the model well to the language

– protect your model

– program for humans, not for machines
– models – UI flow, state/workflow models, class identifications and object associations.. Models don't have to be executable; shouldn't necessarily be a direct input to generating code; might just be a useful way of looking at the problem domain.

– declarative DSLs (XSLT, BPEL, etc) – can be very expressive, but they're almost impossible to debug and the tooling is generally not as good

– Don't allow cruft from APIs to bleed into the domain classes; facade away things like java.util.Calendar & associated horibbleness

– protecting your model – if you make your code accessible then people are more likely to understand it enough not to break it – program for people, not for machines.


- 8 comments by 2 or more people Not publicly viewable

[Skip to the latest comment]
  1. Robert O'Toole

    "understand your domain" – perhaps in a complex and diverse domain it would be good to have a dedicated team who are responsible for this, and for guiding development. Perhaps if they were embedded with the clients and even doing similar work.

    16 Jun 2006, 09:35

  2. Chris May

    Absolutely disagree. Every time I've worked with a 'business analysis' team (which seems to be what you're describing), they've just acted as an impediment, filtering and distorting the real client requirements with their own opinions and prejudices. What's needed is developers who understand the domain, because they have access to users. Putting a middle–man in between is not, IMO, helpful.

    Often the counter–argument comes that you need business analysts because the users requirements are somehow too difficult for the developers to understand, or that the users don't understnad their own requirements as well as the BAs do). But if you're in that first situation, then adding business analysts won't help, because ultimately the developers need to understand the problem domain. And if you're in the second situation, then the role of the BA is to help the customer understand their own problems, and then get out of the way, allowing the customers to talk directly to the developers

    {rant ends}

    16 Jun 2006, 09:48

  3. Robert O'Toole

    You misunderstand. I am arguing for developers who understand the domain. I suspect that you have rather a territorial notion of what constitutes a team. I suppose the moot point is: who qualifies as being part of the development team? Well you certainly can have a successful team of people who spend lots of time working closely with the domain experts, and yet still at some points move back into the software design or even coding process to ensure that what gets built is actually appropriate and useful when they get back out into the field. This is all part of the development process, and hence the development team. The positions within the team[s] are then more fluid and agile. I argue that in a business as complex as Warwick this is essential. If you don't think Warwick is a complex domain, then may I invite you to come and spend some time with some of my clients. Perhaps one of the surprisingly complex Italian Department courses?

    The one (very) big development team that I have worked in, Abatec (developers of the most popular corporate tax software), worked in just that way. I even had to go on accounting courses! Perhaps we should send you to seminars in the History of Art to get a better understanding of how images are used in that particular branch of the business? Personally I find working in such a fluid way to be very productive, and actually quite exciting. If only everyone recognised the value of such work.

    19 Jun 2006, 10:27

  4. Robert O'Toole

    "choose a language to represent the model" – and furthermore, a complex domain deserves a sophisticated language in which it is described. For example, how exactly do we describe this kind of object/activity? We haven't got the terminology for it. I can't easily refer to it in one of our conversations. And yet it is a key part of teaching and learning in the arts.

    19 Jun 2006, 10:57

  5. Chris May

    you certainly can have a successful team of people who spend lots of time working closely with the domain experts, and yet still at some points move back into the software design or even coding process

    It depends on how the 'at some points' works. If you have developers who spend lots of time working closely with domain experts, then go back and write the functionality themselves, then that's good. But if you have a team that spends lots of time talking to domain experts, then goes back and tell someone else what to code, then I believe this is counter–productive.

    I've never tried to suggest that we don't have a complex domain here at Warwick; but whether or not the domain is complex is a non–issue; ultimately to produce a good solution the developer will have to understand the domain, and so the imposition of an extra layer of people between the problem and the solution is just communication overhead.

    I suspect that sending developers (myself included) out to learn more about how lecturers and others use our systems would be useful. When I was at ScotAm I did about 3 years of study towards an actuarial qualification (and spent a hellish couple of weeks in the call centre!) , when I was at Shell I spent quite a lot of time doing CAD in the drawing office – it's not at all unusual. Having developers who have first–hand experience of how the systems are used is a much better investment of resources than just having messengers to go between the two.

    20 Jun 2006, 16:34

  6. Chris May

    a complex domain deserves a sophisticated language in which it is described

    Maybe, though it's important to draw a clear distinction between a sophisticated language and a complicated one. The job of a DSL is to communicate; a DSL which is so arcane that it's readers struggle to understand it is less use than one which is comprehensible, but can only describe a subset of the domain. At least the latter case will allow you to solve some problems.

    20 Jun 2006, 16:38

  7. Robert O'Toole

    What we need is an adequate language.

    As for getting the development team out into the domain, the problem at Warwick is that it is actually quite hard to get access to the domain in sufficient depth. Hence the more subtle aspects are filtered out and the more obvious and easily understood get promoted in significance. Of course, the users have to understand that if they want good software they have to support the development process, and that means that they need to be more involved.

    The trick that I am using is this:

    1. build some code or provide some gadget that might possibly fit into the core provision at some point in the near future, and is based upon an educated guess as to what might fit with the domain;
    2. take it out into the field and show it off, even letting some people who might be useful domain experts try it out live, but subject to clearly stated limitations;
    3. if it does fit, then you have a new feature that meets some genuine need, and also expectant users who are more willing to get involved with the development process;
    4. if they really do want it, then they will be prepared to put in the extra work required rather than see the trial feature withdrawn.

    However, for this to be convincing, any such Incubator Features that do hit the mark must then be incorporated into the core systems. To ensure this, there needs to be proper coordination between the incubator process and the core development process.

    The end goal of this process is to build a larger, more committed, and better educated set of domain experts, able to communicate more clearly with the developers. That, I argue, should be one of the main goals of the E–learning Advisor Team. I hope to see it happening in the E–learning Forum, but its going to be a hard slog, especially if I am working without support.

    20 Jun 2006, 23:06

  8. Robert O'Toole

    I somehow managed to avoid the call centre! Hell indeed. Although the coke snorting trainees were bad enough.

    20 Jun 2006, 23:09


Add a comment

You are not allowed to comment on this entry as it has restricted commenting permissions.

Most recent entries

Loading…

Search this blog

on twitter...


    Tags

    Not signed in
    Sign in

    Powered by BlogBuilder
    © MMXX