Why typical software design isn't common

posted by Jeff | Wednesday, June 18, 2014, 9:42 PM | comments: 0

As my contract gig ended, I started a new job where I've assumed the role of technical architect. It's a little like a cross between a development manager, development lead and traditional architect role. I'd like to think that it plays to all of my strengths, but I suppose I'll have to still demonstrate that!

In any case, the first project that I'm on is one that already exists. I think I can safely say that most people in development circles would prefer to just land on something totally new, because inheriting a project often means taking on a train wreck. Not so in this case. Everything is generally designed and laid out as I would expect it, using predictable and manageable patterns. It doesn't try to reinvent things, and it has mostly grown in a sane way. I still have the burden of acquiring a lot of domain knowledge and such, but I won't be stuck scratching my head constantly trying to understand what the hell is going on.

I complimented the previous TA, indicating that it was pretty easy to understand how the solution was set up in the bigger sense. What he told me is true: "This is just typical industry practice on this platform." He's totally right, of course, but why aren't these typical practices more common?

My opinion is that it's the usual education and experience problem. It's surprising how this kind of knowledge is not frequently shared, but I also suspect that it's partly because it isn't generally a solving a problem that people are thinking about. It's fairly typical to search StackOverflow for a solution to a specific problem, but I don't know if anyone really starts a project and says, "How should I build this?"

So how do people arrive at a place where they have this knowledge? For me, I can only say it's because of my experience and interaction with other people. This is obviously not ideal for the profession, because it's hard to say how one can encounter the right people and circumstances. In a general sense, sure, it's not uncommon for people in tech heavy markets to change jobs every 18 months, but that isn't the case everywhere. You also can't necessarily be sure about what you're getting into (though I would argue that you should be asking good questions in the interview process... it's still a worker's market in most places).

There are really two ways to solve this problem, from two directions. The first is to make sure that a company or development team has someone with these "typical" design skills. That might be a little tricky if the hiring manager isn't a technical person, but certainly there are a million staffing companies that want to help you with that. The other way to attack it is from the individual developer angle, by getting folks the information and mentoring that they need. This requires a certain level of self-motivation on the part of developers, but I generally have observed that they'll come along for the ride if you offer.


Comments

No comments yet.


Post your comment: