Posts
463
Comments
319
Trackbacks
1
Programming without Subject Matter Expertise

In a previous post, I tried to make a point.  I think I did make the point, but it was kind of hard to decipher.  So, here's a (please God I hope more succinct) stab at it.

Learning to be a good programmer takes skill and effort (the rest of us get by on looks and charm).  Learning patterns, OO principles, and the like are all ways that you can try to make yourself a better programmer.

Learning to program within a domain (whether you explicitly follow DDD and have a Ubiquitous Language or not) requires learning something about the domain.  Or at least whatever piece of it you are working on.

*But* in most/many/some situations, the true Subject Matter Expert (SME) isn't a programmer.  And so they have to 'dumb it down' for the development team, because the members of the development team can't be expected to know what the SME knows.

I think this has a lot to do with why software development fails often times.  The SME can tell you after the fact that the software didn't deliver what they wanted.  Things like DDD/TDD/BDD/ are supposed to help in this area, and I suppose they do, but often times, the SME has implicit knowledge that they don't know they need to make it explicit, e.g., 'When I said I wanted X, of course I meant that Y and Z should also be true'.

At times, there seems to be this assumption that by having a back-and-forth conversation between the SME and the dev team, you can have user stories that just work.  But there is a reason why you have to go to school to get a degree in Finance (as an example).  You can't just have 'conversations' and expect a developer who doesn't have the educational background to understand what the SME is saying. 

In the best case scenario, the developer will be able to fake it enough and ask the right sort of questions along the lines of 'what do you want this screen to show', and that is actually a very good skill to have.  But it is a reactive skill, not a proactive one.

posted on Thursday, August 21, 2008 7:29 PM
Comments
# re: Programming without Subject Matter Expertise
Ryan
8/22/2008 8:25 AM
Better. Less drunk. I actually agree.
# re: Programming without Subject Matter Expertise
Justin
8/22/2008 10:09 AM
Have you read Domain Driven Design by Evans? A large portion of the book is devoted to this topic.

I think you might be overly discounting the ability of the developers to learn. Obviously there are going to be cases where the appropriate implementation has to deal with extremely in-depth knowledge, but shouldn't these also be forcing the developer to make a lot of assumptions? At that point a developer ought to be taking a step back, realizing they are operating without necessary information, and consult with the SME for those answers.
Gravatar
# re: Programming without Subject Matter Expertise
jdn
8/22/2008 10:42 AM
Depends on the domain. At one previous client, the SMEs had degrees in chemical engineering. The idea that the programmers could learn chemical engineering through user stories, etc. is a stretch, to say the least.

If the domain involves ATMs and (maybe) flight paths, perhaps it is more likely.
Gravatar
# re: Programming without Subject Matter Expertise
Angus McDonald
9/8/2008 8:14 PM
Been there. Done that. Got the scars to prove it. When the subject matter is payroll and the expert really doesn't want to 'worry you', it can bite. Big time.

Having explicit test cases can help (a lot). At the very least it makes it easier to be specific about what went wrong. Sometimes though the problem isn't the communication of ideas, but the budget allocated to the time spent communicating. Business people rarely value this area correctly and developers often make the mistake of assuming that if the business people say they want to cut that area, then they must understand the impact it has on the project's success.

Post Comment

Title *
Name *
Email
Url
Comment *  
Please add 5 and 8 and type the answer here: