Building Alien Artifacts

I work for a consulting organisation which specialises in solving hard problems and working with in house development teams to transform the way that software development teams work. I haven’t always worked there, and this particular blog isn’t solely about my experiences with ThoughtWorks, but a general observation about working with other people.
One of the things that I worry about is a behaviour which I shall call “building alien artifacts“. This is where an external team (it may be external consultant, or in-house people, or even just senior people within the same department) help build a project in a manner that the incumbent team cannot fathom, maintain or update safely. Essentially an alien has dropped this highly useful, well built device into your lap, and if you press the wrong button, or combination of buttons, it’s likely to explode or at the very least give you a nasty shock. To reinforce what I’m talking about here, the aliens have built a good system, not some piece of crap that can’t be maintained, but the how and why is beyond the capabilities of the team who must take it over.
To me, this is an important part of working with other teams of people. I don’t want to leave people with an alien artifact, I want to leave them with something they can understand, tinker with and improve in safety. I do want to stress that this isn’t a function of absolute experience, or absolute skill, as the same effect occurs if a “database guy” develops a bunch of stored procedures or a data model that the development team doesn’t have the ability to work with. Both groups (database and development team) may have equivalent skill level in their domain, but the effect is the same, the development team ends up with an alien artifact.
Now that I’ve described the situation, what do we do about it ?
The most important thing is to talk to the team and understand where there strengths and weaknesses are. It’s never been my observation that the teams that I’ve worked with in this situation are raving lunatics that should be taken out and shot, they’re generally reasonable quality, hard working developers that know a certain amount of stuff about various things.
After you understand what the team is like, the next thing to do is to understand what can be done. Can we improve the skill levels to the point that might be required, or do we have to look at building a solution that is relevant to the team.
Generally it’s not a binary choice, but there is somewhere in between that is the right place. Sometimes organisations want to embrace change, organisations that have a culture of excellent, or a desire to grow their people are great at pushing the envelope. Sadly there are organisations that resist change, and this is where it’s important to not let enthusiasm for developing a fantastic system get in the way of understanding the sort of legacy you will be leaving behind. All the unit tests, checkstyle rules, jdepend controls that have helped during development will slowly be dismantled after you leave if the incumbents do not understand what’s going on. The project will become brittle and fail. Maintenance will become harder and harder.
Sadly, I’ve come across far too many people with the view of “well, screw them if they’re too stupid to keep it working”. Everybody who works as a consultant, or as an advisor, or as a mentor to teams needs to understand the legacy they are leaving and while they’re working on these projects need to continually ask the question, “Am I leaving an alien artifact as a legacy ?”
If you do, then that’s your fault, and not the fault of the team unfortunate enough to be left with the results.

Advertisements

13 thoughts on “Building Alien Artifacts

  1. Well said. Reminds me of generalizing specialists (http://www.agilemodeling.com/essays/generalizingSpecialists.htm).
    Unfortunately, I can’t help thinking how so many managers of such consulting company would prefer selling more time & materials to the client to keep that alien artifact working… I’d say we better educate the clientele to demand more before we can see any kind of change in the gray mass of software service providers.

  2. Avoiding alien artifacts is a laudable and lofty goal, although it’s a “non functional requirement” and very difficult to quantify. It’s been my experience that when the rubber hits the road, getting the application into production trumps all other objectives, no matter in how much esteem they are held previously.
    I can really see how cosourcing and/or pair programming with the customer can assist with this goal. Given we agilists tend to eschew documentation whenever possible, nothing is guaranteed to give someone a better knowledge of the bowels of an application than being part of the development team in the first place.
    Of course, there is also an argument that if the customer needs to get intimate with the bowels of the application (assuming they’re not continuing development), then the battle has already been lost…
    Accordingly, I can see real dangers of alien artifacts springing up like statues on Easter Island as a result of offshore/outsourced development where code is “thrown over the wall to a customer”.

  3. “nothing is guaranteed to give someone a better knowledge of the bowels of an application than being part of the development team in the first place.”
    The only flaw I see in this logic is, if the client could devote that time to coding, or to pay his own employee to pair programming, one has to wonder why they are paying a contractor/consultant the big bucks in the first place. At least I wonder.
    Sure, there are situations it _might_ make sense. 1. The client or his staff just doesn’t have the skills – in which case, is it a good idea for them to be “maintaining” the code anyway? If they just need to be able to change a few settings, giving them a self-documenting config file might be a better use of everyone’s time.
    2. The client/staff don’t have the skills but have time to _either_ take a class/get up to speed _or_ build the app, but not both. In this case, paired programming with a contractor _might_ be the best use of the client’s time and money.
    3. The client is tech-savvy but not really a coder and has no tech staff. In this case, it’s probably a toss-up of whether the client can afford to spend the time looking over your shoulder and whether you want/like spectators.
    Aside from that, most of the time, if a client has the man-hours to spend on a project and enough general in-house programming man-years of experience, does it make business sense for them to pay the (typically) high cost for a contractor/consultant while continuing to pay their staff/themselves to ride shotgun with the consultant?
    Only if he has a really good tax lawyer, IMO.
    What am I missing about that scenario?

  4. (…anonymous because some of the following could be considered sensitive if you knew which companies I was referring to. Sorry, red tape sucks…)
    > if a client has the man-hours to spend on a project and enough general in-house
    > programming man-years of experience, does it make business sense for them to pay the
    > typically) high cost for a contractor/consultant while continuing to pay their staff/themselves
    > to ride shotgun with the consultant
    I think it regularly makes sense to cosource.
    We do quite a lot of it these days.
    Main reasons
    1) Building a system often takes a lot more resources than maintaining it. There’s a few ways to build up a team large enough to take on the project
    a) Hire permanents
    b) Hire contractors
    c) Hire consultants
    there are costs/benefits for all those, and we generally use a mix of each.
    2) Talented people without appropriate experience are not as productive as talented people with appropriate experience.
    * Often permanent staff will lack the broad set of experience to solve some technical problems. If you’re not primarily a java shop then you might lack experience in JMS/JTA/… consultants/contractors can provide you with people who a battle-hardened, and can provide appropriate technical expertise. Or appropriate process expertise (e.g. If you’re moving to an agile development process)
    * But consultants usually lack the specific domain knowledge to be really able to satisfy business problems on their own. Your permanent staff know your business, they know how the systems work, they know the history behind things. That knowledge is incredibly valuable. It is worth having on a project.
    3) Consultancies will often bring some IP, and a collective set of knowledge. In a good consultancy
    hiring a couple of people onto your project gives you access to the combined knowledge/experience/resources of a very large group of people. e.g. Jon might know very little about using JMeter, but he can send of an email to other Thoughtworkers who can solve specific problems for you.
    So, getting a few consultants onto a project is useful even if you want to mostly staff it with permanent employees.
    Granted, most of those situations are quite the ones you were referring to, but they’re probably more common than yours.

  5. Jon,
    Suspecting I am tech-leading a project at high risk of creating an alien artifact, I am as ever made wiser by your input. On the whole, however, I think the folks you describe have no motivation more complex than getting the system built on time and on budget, and have generally been given this role as the incumbents are not capable of doing so for whatever reason. All the checkstyle, jdepend and what not miscellaneous tools are there so we keep ourselves honest about the outcome of what we are doing. Other folks with different agendas could do the same to make sure they get out of a project whatever they need. I must admit, while valuing the positive and enriching experience of all coders who come after me on the system I’m building, shame of it is, there’s enough to think about right now that the remaining bandwidth for that stuff is doubtless insufficient. However, I’m sure you’re not suggesting just building enterprise apps a la Core J2EE Patterns 1999 edition if that’s where the team is right now. We have to do better each time, and if the customer has hired a bunch of guys who don’t get OO, do you want me to avoid using it? I would hope I’d be allowed to consider that somebody else’s fault!

  6. While I wouldn’t say one way or the other what is the appropriate path to take, I would always caution people to accept the risks associated with creating alien artifacts.
    There may be circumstances beyond the control of any parties where the artifact is created.
    However, in my experience the artifact is created and there is no thought to any of the risks involved, nor is there any thought to raise the issues to the customer about what is going to be required to keep this project adding value for many years to come.
    In some cases this might be training for staff, in other cases it might be comprehensive documentation. I can see places where a long standing retainer for the development team (remember I’m also talking about in-house projects as well as external consultants), or hires to flesh out the maintenance effort.
    None of these are inappropriate, but like the page that says “Intentionally left blank”, I like to make sure that these decisions are made with adequate thought, and not left as a de-facto decision because nobody thought that this might be an important consideration.
    And yes, I do believe that there are situations where building systems “ala Core J2EE Patterns circa 1999” makes sense. Of course, I’d also like to think that these decisions are made early enough in the project lifecycle that should the long term prospects of the project, and the chances of success on the project are not sufficient, that people have the opportunity to decline the invitation to participate.

  7. Unit Tests As Complexity Sponge

    A number of people have variously commented that unit tests may in fact be more about design than actual testing. Many others (the links elude me at present) have also complained about the undue burdon imposed by a large number…

  8. At my last job I left some pretty fantastic alien artifacts. The greatest irony was that I was the middleware guru so I wrote the foundations of 90% of their applications so they can’t just ignore it. I feel sorry for the poor computer science 1 student maintenance programmers who are going to have to open up those files some day and have their minds be blown away by all the metaprogramming, reflection, design patterns, lambda functions, language extension and LISP/SmallTalk/duck typing paradigms I shoehorned into a staticly typed language (C# v2.0). The problem was that the architect/my immediate supervisor would come up with these grand ideas that couldn’t actually be implemented. He’d hand me a blue-sky architecture description and I’d have to implement it – the scary part is that I really did implement them, just not in the way he thought. For instance, he’d give me weird requirements like he wanted some class to multiply inherit from both Windows.Form and Windows.Panel – when C# only supports single inheritance. And he wanted me to go back and retroactively insert new base classes into the GUI controls class hierarchy in the .NET framework. Both of these are impossible, but what I did was implemented the system he wanted by using the bridge pattern. Instead of inheriting the classes directly, I made an inheritance hierarchy of adapters that stand in for the GUI elements. This was all part of a custom “presentation engine” for WinForms application that included the kitchen sink – it even implemented a SmallTalk style message passing system so that forms could communicate without knowing in advance who they were talking to or what types they would send! (Can’t statically type something that’s not known at compile time.)
    They wanted other strange things like a client application that connects to a database, but which could work without being connected to a database. That’s fine except that they wanted to insert rows and refused to use GUIDs, only autonumbers, and only the server can generate autonumbers. So they want a client app to be able to insert/delete rows for days without knowing what the autonumbers will be – the only way to make it work seamlessly was to make the data access layer generate “local autonumbers” and then translate those to “real autonumbers” when the database comes back up again!
    I used operator overloading to implement a LINQ-like system in C# – before Microsoft even invented it! (LINQ like meaning that I made it so that you could write code in C# that looks just like SQL but is parsed by the C# compiler and type safe.) It was uncanny how closely my SQL-in-C# invention independently paralleled Microsoft’s LINQ.
    They wanted to use open source CASE templates to generate data access layer classes – but were depending on features that were not really implemented yet; the architect couldn’t tell the difference between the template team’s “finished” list and the template team’s “wish” list. So I had to take this unfinished nightly build of the templates and do in 2 weeks as one man what the entire team expected to do in 6 months. The scary thing is that I did do it, by radically abandoning the way the original templates did it and actually employing a “metaprogramming squared” technique – I used metaprogramming to make CASE templates that generated metaprograms that built data access objects. By first refactoring the size of the templates from 10 to 20 thousands lines to about 3 thousand lines, I could then extend the templates far faster than normal because I didn’t have *type* so much in the condensed notation!
    Yes a bonanza of alien artifacts. When I was criticized by the architect of creating alien artifacts instead of straightforward solutions, it was actually my other team members who came to my defense – they said, “How can you criticize what he’s doing when everything he’s written works flawlessly? Is there anyone else here who could even DO the tasks you’ve been giving him?”
    I actually did feel bad about creating these alien artifacts – but I don’t feel it is necessarily the right answer to dumb down your code. We had situations where we had databases with literally 200 tables. I wrote data access classes that allowed 1 class to handle all 200 tables. It was an alien artifact and thus hard to maintain, but what was the alternative? I could have created 200 “dumb” data access classes, but that would only have created a *different* maintenance nightmare!
    Rather than bringing my code down to the lowest common denominator, I would have loved to bring everyone else up to the “alien” technology level. But in the end the pressure was just to keep banging away at the next deadline, and all my pleas for a chance to document and educate about what I had written were ignored. So when I left, I left a crashed starship in the middle of a medieval castle. God knows what they will make of it in the future.
    I do think that there is a greater level of expertise beyond merely creating alien artifacts. The true skill is to work smarter not harder in that respect but present the code in such a way, organize it in such a way, that even if the technique used is way beyond what anyone else on the team has seen, it can still be understood. By analogy, even if it takes a high caliber of person to invent the internal combustion engine, it is still possible to build an internal combustion engine that can be worked on by ordinary mechanics.
    For instance, there are certain language features that can be used to generate fantastic artifacts – template metaprogramming in C++ is a good example. But what can be done at compile time as a template metaprogram could also be done at run time by composing objects. If execution speed is not critical, this could be engineered to do an *equivalent* thing as the template metaprogram but could be presented in such a way that it wouldn’t require bizarre syntax to present it.
    That’s why I’m so excited about Ruby. Ruby’s duck typing and clear syntax allows me to write programs that would look bizarre in statically typed languages or with templates, but present them in a way that is perhaps easier to understand.

Comments are closed.