Like most large companies with large applications, regulations, policies, and so forth, we have a certain procedure for developing and releasing applications. In theory, that means gathering requirements, building up a design, implementing the project, going through a QA cycle, going through a user acceptance cycle, and then releasing to production. To make things worse, entries have to be made in project planning software, priorities and deadlines need to be set, change management requests have to be put in place and approved, deployments have to be tested … The deployment and support (and indeed the environmental administration, QA deployment and facilitation, user acceptance testing, etc.) is handled by the support entity, of which I am a member. The downside to this process is that even in the most accelerated cases, this means a week or more to turn around a project, and in most situations things are planned in terms of months.
To combat this, numerous groups employ “desk developers” — people with a modicum of development ability and business knowledge. Those experienced in the support arena will cringe, realizing the danger posed by these seemingly useful creatures. The problem with desk developers is they do crazy things. For example, they might go and download libraries and software from the Internet. This is against company policy. Then they build an application that uses the downloaded software, show it to somebody in the business, and get them to say “I want this on my workstation, yesterday.” The thing is, the desk developer lacks this special ability (and with good reason) — they cannot change a protected production environment, even if it’s a trader’s workstation. They do not have administrative rights or the ability to install software. Does this mean they can’t cause trouble? I wish.
The problem now is that they turn their hacked-together application over to support and say “install this!” Usually there’s a small caveat like “oh, by the way, this requires XYZ.NET version 10.14, which isn’t yet approved for use or licensing, but it should be pretty easy, because it’s just like product ScrewYou 5.6. Toodles!” Meanwhile, they write their business client and say “hey, by the way, I’m finished with development on SuperApp, and I’ve handed it over to the support group for deployment.” They have been running behind schedule on their delivery, so the business is already perturbed, and they are now told that support is the only remaining impediment to running their new wonder-toy.
It’s a very hard sell to explain “sorry, the software used by the desk dev is not yet approved for use in the bank” and “the usual turn-around for approval, licensing, purchasing, and SMS packing of new software is 4+ weeks.” The immediate responses are “install it now” and “I’ve been waiting for this for two months.” In the end, unless these desk developers are producing excel macros, fixing borked spreadsheets, and dressing up presentations, they are dangerous and cause pain for the support entity. This is because they have no schedule (visible to the support group), they are unpredictable, they are impatient, they ignore policies, they do things in a half-assed manner, and so forth.
I’m not against the role in general, as having quick turn-around is critical for a fast-changing business, but I think this type of developer needs to have a certain scope — they aren’t there to build complicated windowing .NET applications, they are there to build mock-ups and excel macros. When things get professional, it’s time to involve a proper development lifecycle. I suppose I’m just whining because I am bitter about the hassles these sorts of developers create, but I feel like there is little point to having a system if it is not respected.