Statically Typed

because Hindley-Milner rocks

Defining a Good Development Environment


I was asked what I thought defined a good development environment and the answer I gave to that question utterly failed to capture what my experience has taught me.  First and foremost are the people, the roles they play, and the contributions they make to the team.  Next, is the office environment: the development machines, internet connection, and available software.  Finally, I think the last part of the equation is the relationship with the customer/end user.

1. The Requirements Gatherers

These are the people whose task it is to transform the idea of the customer into a conceptualized list of specifications which describe the end product. The best people I’ve met who perform this role well are those who tell a good story.  I’m not talking tall tales, those golden tongues work in sales.  No, I’m talking more about the type of people who instinctively know where a movie plot is headed next, groan at the predictability of daytime TV and can guess a joke’s punchline before it’s delivered.

Good requirements people ask good questions and have an intuitive knack for ferreting out unspoken customer wants.  They’re patient listeners who can work with all sorts of social awkwardness to guide the rest of the team to completion.  In short, they’re good communicators with a sort of precognitive sixth sense.

On the other hand, if the words “The customer has no idea what they want” escape the lips of these people they are not asking the right questions.  Hence, they are not getting the right answers.  Whatever it is the customer wants, you are not going to make it the first go around.  Maybe by the third or fourth time unless you have the most extraordinary sales department.

Watching a project unfold with poorly defined specs is like watching an accident in slow motion.  Throw in a hard set deadline and the code will undergo the most extraordinary metamorphosis from benign inch worm into a Frankenstein monstrosity the likes which would give the fabled Moth-Ra a pause.  And the problems won’t end there.  Maintenance costs will increase, bug fixes will take forever, feature creep will become the status quo, and the code structure will degrade swiftly.  I’ve seen a product idea transform from a plug-in for a .NET application to a C++ stand-alone application to a Java exposed application framework complete with API integration into a third-party library for use by future developers.    Try planning out an architecture with that in mind.  It ain’t pretty.

2. Sales

You’ve already met enough salesmen in your life that I don’t need to describe their purpose.  That being said, their role is something more profound depending on their influence of the final product and the customer expectations.  Good sales people are team players.  They form relationships not only with the clients but also with the product managers.  Keeping tabs on upcoming features, making sure previous purchasers are happy, and taking feedback is just as important as the sale to someone who prides themselves on a job well done.

The true mark of excellence is making sure their promises can be met by the development team before they make them.  Any talk of schedules is done in consultation with project managers.  Any thought of reducing the bid price is reviewed by both the business development and the engineering team.  Fundamentals come first, commission comes second.  Sacrifices are asked for once in a blue moon and remembered.

The problem facing the sales team is that customers always want something cheap, next week and feature deep.  Bad sales people compromise company integrity by promising the world and leaving the requirements analysts to deflate expectations.  Customers won’t just be upset they aren’t getting what they want.  They’ll perceive the situation as if their contract is trying to be renegotiated.  Worse, it could be assumed you’re lazy, incompetent, or plain out to screw them.  That client will take their business elsewhere all the while the salesman will be thumping the table insisting that they, unlike you, did their job well.

3. IT

Personally I don’t care if they’re wart covered troglodytes or sparkly haired socialites.  Like the CIA, if they’re competent at their jobs I probably won’t notice even half of what they do.  As long as they keep abreast of the latest technological trends, show a skeptical attitude to product peddlers, keep things running smoothly, don’t interfere with my development activities and avoid the cross hairs of the executives I’m happy.  I bet they’ll be too.

But the IT world is a screwy place.  These guys need to be able to say “no” and put the fear of God into other peoples souls.  If they lack the skills to stop an executives misguided attempts to “improve” the Internets with this “great idea” then you’re on your own.  They’re probably up to their elbows in it and if you stand too close, so will you.  I will admit I don’t understand how or why things in the IT divisions get to the point that they do.  That’s for someone else to discuss.  I just mention it here because you should thank them.  Daily.

Good IT groups listen and adapt to the needs of a development team.  It can be as much as developing custom installation scripts for a development environment conforming to some odd-ball contractual obligations and as little as resetting a forgotten password promptly.  The best IT professionals have a sense of humor and a competitive attitude.  They’re composed of people who are vying for that #1 spot or the title “go to guy” in the office.  I’m not saying they drop everything just for you.  I’m saying they make time where it’s needed most and explain to you why you’re not the top issue.

Bad IT groups don’t listen and don’t care.  The loudest complainer gets addressed first.  A symptomatic peculiarity of bad IT is the formation of a bureaucratic wall with a claim that it is supposed to “expedite” issues.  Thus holed up in an ivory tower somewhere far, far away they are free to decide what must be done with as little input as possible from those they are supposed to be helping.  I’ve seen IT departments insist on placing whatever applications they deem necessary in the test environments despite the protests of QA, project management, and developer teams.  I’ve seen them take days to install Linux and minutes to remotely uninstall IDEs while in use.

4. QA

I think QA and product testers go hand in hand.  If a customer can’t tell how to use your application when it’s delivered no amount of QA is going to fix the problem.  On the flip side if the interface is an artistic statement worthy of the Louvre but it crumples like some dried out husk of parchment no one will use it.  Apple scores big with the masses because of the zealous focus on industrial design and product quality.  In this respect I want to be like Apple (without a product approval Labyrinth and patch passing quagmire) and to do that, I need a superb QA team.

A good QA team makes sure the right issues reach the proper person.  They stand not only between the out going direction from production environments and development environments but also the incoming direction as well.  Just being able to figure out how to reproduce a bug is not important enough.  User bug reports need to be tracked to discover hidden defects which while not a true bug-in-the-code sense could point to an architectural problem or unintuitive feature.

As a contemporary example Microsoft found that the most requested features for their Office products already existed within the product.  For a while they did not accurately diagnose this as a profound defect.  It wasn’t until someone stepped up to find out why that steps were taken to address it.  The final solution was the ribbon.   Here is the story of the how and why it happened.  I can find no better example of a QA success story than here.

5. Developers

I think only the number of stories related to bad managers can eclipse the number of stories centered on bad developers.  Unfortunately half the time it’s the bad developers telling those stories.  We all know what a bad developer can do to not only a project’s schedule, the group morale, but also our own performance (and subsequent performance reviews.)  Bad developers bring everyone down.

But then what is a good developer?  Every time I hear the term “good developer” thrown around I also hear the phrases “passionate,” “intelligent,” “hard-working,” “tireless,” and “gets things done.”  I have yet to figure out what “passionate” should mean.  Half the time it sounds like X technology evangelist.  To me, I’d take “constantly seeking to improve,” “accepting of criticism,” “humble,” “considerate of others,” and “introspective” over all of those qualities.  This comes from my own experiences, yours glasses might be colored differently.

I’ve worked with a “gets things done”-type.  Code was written with such celerity that it boggled the mind but the quality of code in terms of readability and maintainability was poor beyond measure.  I’ve also worked with “intelligent” people, too.  The ideas were great but it took 3 months to deliver a 2 week task.  I wouldn’t have had a problem with either of the projects running 10 or 20% over schedule if it meant that the next iteration with it went smoother but at some point I’ve got to be pragmatic.  You can be “intelligent, tireless, hard-working, and gets-things-done” but if you prevent me from getting things done you’re not helping!

Good developers, therefore, have an eye for long term goals.  They write code that others can use.  Their code is expressive, self-describing, and “dumb.”  When I talk about “dumb” code I’m not saying it can’t contain fancy things like closures, multi-threading, or customized memory pools.  Instead I mean more to the adage which states “In order to debug code you have to be twice as smart as the person who wrote it…”  So a trait of a master is someone who writes code so crystal clear that any idiot could figure out what it’s supposed to do.

6. Management

I’ve got one good manager I work with on a day to day basis.  I’ve also had my fair share of not so good managers.  Their influence on a project is without question great.  But much like my description of IT I think it would be disingenuous of me to describe what constitutes a good manager seeing as I’ve never managed.  So I really don’t know.  I hope that will change in the future.  I hope one day I’ll be able to come back and rewrite this part with greater insight into the challenges they face.

All I can ask is that my manager listens well, negotiates well, is technologically savvy, and most importantly asks what he could do to remove as many development obstacles in our way as possible.  If he’s fair in his criticisms and approachable I’m pretty happy.  It really doesn’t take much.

Conclusions

Well, I guess there could be other roles I’ve not even considered or thought about in this little spiel.  I did mention three different things but only talked about roles here.  For me this was more about getting out something to answer a question I knew I should have been able to answer but couldn’t formulate into words at the time.  I probably shouldn’t even make this public like some of the posts I have sitting in my queue.  Then again, what harm can it do?

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Information

This entry was posted on August 15, 2010 by in Software Development.
%d bloggers like this: