The Multi-user Unstructured Development (MUD) Process

The MUD process is a mature, widely-utilized software development process. It can be found in thousands of teams around the globe. Its primary aims are to allow developers to work simultaneously on a wide variety of projects without all the willy-nilly management cruft associated with other so-called “agile” processes.

MUD is characterized by several important features:

  1. Total absence of friction-heavy “code management” strategies. This includes the use of tools like source control as well as formal project plans and development standards. It takes a great deal of courage to go without these crutches, but the eventual outcome is that a team can write code as fast as their hearts desire.
  2. Total absence of politically-fraught “testing” strategies. Teams are encouraged to formulate their own validation processes. Without the normal multiple-back-and-forth cycle of testing, release cycles can be radically shortened. This is another point that requires lion-like courage, as teams could theoretically be shipping software with bugs if they don’t do full, formal testing.
  3. Speaking of which, total absence of any kind of “code validation” technique. Individual programmers are assumed to know what the hell they’re doing because sure as shit nobody else does, and good luck if they get hit by a bus. Coders should ideally be provided with Iron Man suits just in case they get hit by a bus or, more likely, have a heart attack.
  4. In fact, to hell with it. Just chain them to their desk until the customer says they can leave, which will be never. I would like to point out that this is still better than working at Electronic Arts, so be grateful, ya punk.

The MUD process produces functional code on a surprisingly regular basis. It gives people the freedom to stay at their desk rather than wasting their time trying to be something they’re not. To quote the MUD manifesto, written by Some Software Development Manager Guy:

”Uuuuum, we need that by Monday. Do whatever you have to do.”

This Is What I Mean About VS Tests

This is what you get by default when you ask Visual Studio 2008 to generate a new test:

WHY!?!?

WHY!?!?

Why is that so cluttered? Why is there a region that is filled with test-writing tutorial code? Why is there a member variable to track the test context? WHAT THE FUCK IS GOING ON????

*Ahem*. Yes. This is way too much code, is my point. I want to see two things when I generate a new test case:

  1. a test fixture (ie a class)
  2. an empty test(ie a method)

If you watched the video I linked previously, you’ll notice that they actually do meet these criteria. Which is good! It’s just too bad that they’re building the clumsiest interface possible over top of that.

(PS: Hilarious ironic factoid – I can’t upgrade to this newer, “better” test tool because I can’t install VS2012 because I still have Windows XP. Speaking of being the victim of Microsoft’s successes…)

Visual Studio Unit Testing: Bad? Or Truly Awful?

I’m learning the built-in unit testing framework for Visual Studio right now, and I have to say, so far I hate it. I found this video, and it made me physically sick to watch it. The interface shown may as well have been drawn in Paint, and while it appears to be functional, it hardly drives good behaviours. In 2013, I shouldn’t need to tell anyone that an interface should be attractive and helpful. I also shouldn’t have to tell anyone that I expect control+mousewheel to resize the interface.

I’ve been programming since I was 8, or maybe since I was in high school, depending on exactly how you choose your definitions. Now, at the unbecoming age of 35, I still think of Microsoft the way they were in the 90s – a tools company that eats its own dog food. The problem I’m having is that I couldn’t tell you the last time something from their stable really impressed me.

Actually, yes I can: the first time I used LINQ to navigate collections. And maybe that’s a big part of why that video made me sick, because it drives home the realization that that wonderful moment was half a decade ago. Everything I’ve done with Microsoft tools since has been kind of shit.

They have this problem a lot, kind of becoming victims of their own successes. IE6 was the albatross for a long time, and its legend will live on eternally in quirks modes everywhere. But .NET is the heavier of the two for the maintenance guys of the world. Microsoft built some really incredible tools (like that LINQ idea) in later editions of the framework, but for much of the world the toolset may as well have ceased updating after 2.0. Even generics, a shockingly simple tool to use, gets too little use in my experience.

I don’t really understand how MS does this again and again. Maybe it’s something to do with their overreliance on the conservative don’t-break-it culture of corporate customer. That kind of makes sense to me; at this point .NET code can feel a lot like COBOL – it works, so nobody touches it, and there’s no point trying to get fancy all these years later.

Lately I’ve been playing around with Java, Android and iOS, and their environments certainly look a lot like Visual Studio. But they are much better in some senses. Eclipse in particular is kind of a beautiful tool sometimes. It’s dog slow, especially when you’re used to Visual Studio’s Intellisense, but the explicit notion of Perspectives is something that I appreciate because it occurred to me, as it probably does to a lot of guys, after several years of trying to serve several masters in a single product. After a while, even the low-end guy, the maintenance monkey, wants to take up a wrench and put a bloody filter on application functionality, because maybe that will shut up the engineer who couldn’t place a PO correctly if his stinking life depended on it.

I suppose I should get back to it. Expect more on this theme in days to come.

Excitement and Day Jobs

I have been trying to bring my excitement and creativity to bear in my day job. I assume there are a lot of different ways to do this, but in my case it almost always involves generating a new idea that is nearly or completely orthogonal to my normal duties.

In particular, I’ve been playing with two things. The first is my other life as an artist. In that life, I’m writing a couple of graphic novels, and over time it’s become apparent that I’m going to need to draw them. These are projects that are kind of immense in scope, so they’re not appropriate for a short-term partnership, and I’m not interested in cutting them to be better suited to that model. So I have to learn to draw. In service to that, I’ve been finding reasons to draw at work. I have a bunch of sketch dumps from my paper efforts; some of those are decent, but most aren’t. But I draw almost every day, and I have models for my efforts thanks to the ubiquitous Team Meetings that are so common in our environments. These are the tools one needs in order to improve, after all.

This has lead to my having developed a reputation as an artist in my team. It’s nice, in a way, because it means people think of me with that aspect in mind, and so they occasionally toss a request my way that gives me an excuse to draw for no better reason than to try my hand at it. And because of that, I’ve been asked to do a comic for the corporate newsletter. It’s been a pretty rewarding experience, and even if I don’t get it completely finished, I’ll be glad to have taken it on.

The other thing I’ve been playing with involves my interest in crowdsourced and –funded initiatives. It seems like these are falling away a bit lately, but my hope is that they are simply settling into a workaday omnipresent mode; basically, I’m hoping they’ve passed the hurdle of acceptance and are now deep into the optimization and competition phase of the business cycle. I think they probably are.

I am very much a hammer-sees-nails guy, and so I’ve been bending those crowd-driven model to a lot of problems. At work, that’s meant I’m always looking at our processes through the lens of ways to better solve problems by taking advantage of pooled brainpower. So I’ve been developing a proposal, which I am hoping will eventually bear fruit, to take a crowd-driven approach to Professional Development. It’s a natural fit, and it’s something that my employer already takes seriously. Better, IBM does it already.

I’m telling you all of this not because you need to know what I’m up to, but because it’s all stuff that isn’t my day job but that I’m bringing to my day job. On the days when I can’t bear to look at another half-assed piece of code, this stuff gives me a reason to look around and see what else I can bring to my work. Ideally, it gives me a reason to exercise my creativity and a reason to come to work with joy in my heart.

I think those are ends worth investing in.

Settings Files

I’ve been writing .NET code since about 2004; the period from 2007 through the end of 2012 was dominated by this platform. And in all that time I never once created a settings file. They seem fidgety, but my goodness aren’t they ever handy!

Formatting SQL

Originally posted on StackOverflow.

When it comes to dealing with complex SQL, it has been my experience that using vertical space liberally is your best friend, particularly once you move to systems with more than a single join in most of your queries.

I’ve written a code standard that I have been using for about 5 years.

    SELECT 
        column1, 
        column2
    FROM 
        table1
    WHERE 
        column3 IN
        (
            SELECT TOP(1) 
                column4
            FROM 
                table2
                INNER JOIN table3 ON table2.column1 = table3.column1
        )

On more complex queries it becomes more obvious how this is useful:

    SELECT
        Column1,
        Column2,
        Function1
        (
            Column1,
            Column2
        ) as Function1,
        CASE
        WHEN Column1 = 1 THEN
            a
        ELSE
            B
        END as Case1       
    FROM
        Table1 t1
        INNER JOIN Table2 t2 ON t1.column12 = t2.column21
    WHERE
        (
            FilterClause1
            AND FilterClause2
        )
        OR
        (
            FilterClause3
            AND FilterClause4
        )

Any code style guide needs to have a goal; this one has the specific goal of making it really easy to read the column list and to discover clause correlations, particularly in insert-select statements. The basic principles of the guide are:

  1. Each clause should be indented
  2. Within a clause, a list of conditions or other “phrases” should be indented
  3. This includes fields or values, which should each have their own line
  4. When a field or value has a complex definition, it should be indented so as to make its structure obvious

Customer Service and Automation

In an ideal world, application maintenance in the enterprise focuses primarily on making an in-production application operate better by pursuing the 20% that other people can’t. In reality, that is something we get to do PART of the time, but there are huge chunks of time that get spent on client service instead. It can really suck the satisfaction out of the job at times.

“Support” isn’t all bad, though. Sometimes being in the line of fire gives the working programmer a chance to fix a process or build a tool that has a lasting impact on an organization.

Take Chris, for example. He’s a plain old engineer by training, but like most engineers born after the birth of the PC, he has gotten his hands dirty with a little code from time to time. I have often heaped abuse on the code turned out by his ilk, but the truth is, it’s not all bad. Chris turned out some Excel tools that did a ton of work for him. One of them was pulling and analyzing files from a document control system and measuring properties of solid objects in a way that I simply wouldn’t understand.
Programmers of that type are valuable for their ability to create tools that encode deeply domain-specific knowledge in an automated way. As a maintenance programmer, I value that kind of code, because it automates something I might not even understand.

One of the ways to gain understanding, however, is to live in front of the support firehose. Chris’s tools almost always came out of a repeated request from his fellow engineers. Sometimes they needed a set of files copied to a particular location. Sometimes they needed to convert files to a new format. Sometimes they needed a way to move data and files to a new location.

Each time the request came in, another little piece of the requirement showed through. Sometimes the next step was to automate the support process; sometimes the business got there first and requested a tool to meet a need that was immediately recognizable as the same kind of thing as one of Chris’s tools. Whatever the sequence, the fact that Chris lived in the support stream meant that he had that deep understanding of requirements I talked about, and that meant he could use his skills as a programmer to build something that made a material difference to the life of the support guy (himself, in this case).

I’m about to enter that support stream. In days gone by, I think I’d be disillusioned. But having spent the last several years learning what I’ve just talked about, I now see the opportunity I’m being presented, and I’m excited by the possibilities.

Requirements

It’s good to be in the mix. If you want to be an architect, I highly recommend being embedded somewhere long enough to see a system die. That experience will change you as a programmer; there really is nothing quite like watching an ancient, code-crufted beast fall over under its own weight as an organization shifts underneath it.

Because the thing is, requirements change. Constantly.

And since we’re the ones pushing for that last 20%, nobody knows that better than us. Packaged-application developers might see specs change until they are frothing at the mouth, but that system that they engineer to within an inch of its life can quickly become outdated or find itself mothballed. Maybe two weeks after implementation someone will realize that the requirement that drove its implementation went away again, or never really existed in the first place.

Meanwhile, business people who “own” (are accountable for) systems that they do not use are beyond fickle. They pitch ideas without ever seeing the system in use. They have a vague idea based on conversations with people whose assumptions go six layers deep, and they only “get” layer seven, which blows away at the first sign of a breeze.

So when someone builds the wrong system, or someone specs the wrong system, or someone implements the right system the wrong way, it’s always the maintenance guy who ends up pulling it out, dusting it off, and chucking it on the chin so it can serve a purpose after all. Call it cost savings, call it repurposing, call it laziness. Any way you call it, it’s a kind of pursuit of excellence that looks, to outward appearances, like contentment with mediocrity.

In contrast with that last 20% of functionality, where the problem is You Can’t Please All the People, what’s really happening in the case of software salvaging is Requirements Are Hard. Agile people get this to some extent – they require that someone from either the developer or the customer “live” at the other party’s environment. What this does, theoretically, is short-circuit the refinement process for requirements – the embedded developer can watch people at work and validate assumptions about workflow and develop an implicit understanding of what people are doing, while the embedded customer can look at the software at its most malleable and respond to its state without needing to undertake analysis.

In both cases, simple usage suffices – a software user using software will always be the best engine of discovery for poorly-drawn requirements.

The maintainers of the world, the programmers-in-the-middle, we live in that place. Always, every day, we can look at what those around us are doing and make the requirements tighter. Maybe it requires a daily walk-around or a cultivation of friendships with the internal user group, maybe it requires some assumption of duties related to the program in use. But the opportunity to learn requirements analysis will never be better than it is when you live in the middle. It’s a skill that gets better as you learn more about more functional areas, as you learn more about more kinds of users, as you support more pieces of software. It’s a good place to be, even if you don’t always want to be there.