Aspergers Software Engineers: a 12 question list by Joel Spolsky that you should use

For those of you in software development who are looking for a way to determine if a place is good to work for or with, I suggest you look at the Joel Test created by Joel Spolsky.  While not oriented towards Aspergers or ASD specifically it does address a major concern that many of us have regarding a workplace; namely, does it aim to produce something that we can be proud of. If there is one unifying thing I have noticed about ASD folk in software development is that we hate putting out schlock.

Joel's test focuses on asking questions about whether the tools and material are present in a company to produce quality software. Even non-software Aspies can identify some of the questions as useful: do you have quality testers? do you have a product specification? Seriously, some software shops are so bad that these would be revolutionary questions. The most appealing question for ASD folk would be: do people have a quiet working atmosphere?

So those of you in IT, the next time you go to interview, take these questions along and check them off as they are answered in the interview or ask them when it is your turn to interview them. Asking questions in the interview is strongly encouraged and here are ready made questions for you that will at least give you an idea if it is a good place to work for you.

And if you are not in IT, consider how they may apply to your own job hunt or check back here... I hope to have my own 12 question check list for Aspies that I shamelessly admit was inspired by Joel's questions.

Aspergers/ASD and Agile software development: Part Three - Documentation

Part three (read Part 2 here) of my series on Aspergers/ASD and Agile Software Development addresses the Agile principle of valuing Working Software over Comprehensive Documentation. In many ways I see this principle as exposing many deficiencies in the software development process as a whole: the misuse of developers as document writers; the overblown documentation that is so pervasive in older development houses; and the antipathy of many developers to document anything (including comments in the code).

I believe that the attachment to documentation by ASD folk comes more from wanting to know what is expected of them and the software as well as the difficulties that verbal communication presents (overwhelming information; unwanted stimulation; eye contact) than a love of documentation for documentation's sake. Keeping this in mind I offer the following pieces of advice:

1. The principle stresses 'comprehensive' documentation but does not totally eliminate the need for some documentation. When interviewing ask what their opinion of 'comprehensive' is and ask for examples. If it is enough for you to get started and puts you in a position that you can learn more about the system then it is probably a good situation. If however they have no documentation or one line documentation (e.g. "add no-balance accounts to processing") run. That is bad practice in ANY development methodology.
2. Use the documentation to launch yourself into a knowledge hunt. Teasing out the information needed can be fun and rewarding in and of itself. Remind them and yourself that their chosen methodology makes this a necessity.
3. Broaden your definition of documentation. I often use server logs, the code base itself, SQL Trace functionality and watching users operate as 'documentation'. In many ways it is more honest than user manuals and product specs as they show exactly how the software operates and not how someone thinks or perceives it should work.
4. Create your own documentation. With the advent of phone based cameras, easy screen capture methods and self publishing tools you can create your own documentation for your use. Who knows, you might even be able to hand it off to a fellow Aspie and make their day.

Going to a loose methodology like Agile can be difficult but it should not keep you from working at a place as long as they follow some basic rules. There is always a need for documentation just make sure it is reasonable. I once worked in a place where I filled out a project document that was 50+ pages long... and I edited 7 pages for a total of 20 lines. Way too much boilerplate information there. On the flip side the one sentence product spec is a recipe for disaster. Find what works for you.

Workplace checklist

I have been working on an article for my business website about a checklist to determine if a workplace is ASD friendly or not... and it has not been going well. I had hoped to pattern it after Joel Spolsky's checklist for good software places to work. Unfortunately a good ASD place has more than 12 characteristics... or I am complicating things too much.

Anyway, if you get a chance check out Joel's site www.joelonsoftware.com as he has some excellent ideas about how to approach a career. You may need to abstract the ideas away from programming but they are very useful.