Search code examples
survey

What is software development at your company really like (methodologies, tools, ...)?

Since I've started my first job as a professional software developer about two years ago, I've read many articles about commonly accepted methodologies (e.g. Scrum, XP), technologies (e.g. EJB, Spring), techniques (e.g. TDD, code reviews), tools (bug tracking, wikis) and so on in software companies.

For many of these I've found that we at our company doesn't use them and I ask myself why. Are we doing it wrong or is it merely that these articles I've read are not really telling what it's like in the real world? Are these articles more academic?

So, please tell me what it's like at your company. Tell about everything regarding software development. Here are some suggestions (in the order as they come from my mind). Tell at least if you do it or not, or give a short comment:

  • Test-Driven-Development
  • Domain-Driven-Design
  • Model-Driven-Design/Architecture
  • Do you test?
  • Unit Testing
  • Integration Testing
  • Acceptance Testing
  • Code Reviews
  • Innovative Technologies (Spring, Hibernate, Wicket, JSF, WS, REST, ...)
  • Agile
  • Pair Programming
  • UML
  • Domain-specific languages
  • Requirement Specification (How?)
  • Continous Integration
  • Code-Coverage Tools
  • Aenemic Domain Model
  • Communication (Wiki, Mail, IM, Mailinglists, other documents)
  • Effort estimates
  • Team size
  • Meetings
  • Code metrics
  • Static code analysis
  • Bug tracking
  • ...

And remember: I want to know what you really do, not what you would like to do or think you should do.

Solution
    • Test-Driven-Development - No way.
    • Domain-Driven-Design - What's design?
    • Model-Driven-Design/Architecture - What's design? We do have an architecture team. With one exception (the most junior architect), they couldn't code their way out of a paper bag. They're sure good at drawing boxes with lines, though! And establishing crappy, worthless, over-generic and completely useless standards. (The old OPC stuff is OK, but the UA standard has been "done next month" for the last 4 years or so.)
    • Do you test? - Yep, we do have a dedicated test team. There's about 1 tester for every 10-12 devs. They're completely swamped. Ask me if we test well.
    • Unit Testing - Completely informal/up to the developer. I do when the schedule I'm given allows for it.
    • Integration Testing - Yes. This one's necessary given the suite of products we develop and support.
    • Acceptance Testing - Yes, for contract-y work only.
    • Code Reviews - Always pay lip service, never ever do it.
    • Innovative Technologies (Spring, Hibernate, Wicket, JSF, WS, REST, ...) - Taking new dependencies is strongly frowned upon. Boost will never be adopted, e.g. We have generally had good luck getting to newer versions of .Net, though, if typically 2 years or so behind the curve.
    • Agile - No. Management claims to want "agile," though they don't exhibit the barest understanding of what it is. We just recently modified our process so that higher priority tasks are spec'd and implemented with... (wait for it) higher priority! Management tells me that this is our new "agile" process. It still smells, walks, and quacks like a waterfall though.
    • Pair Programming - No way! Pay two people to do the work of one? Next you'll be suggesting that developers should waste time on nonsense like designs and code reviews. Dogs, cats, living together!
    • UML - No. We got a UML tool once to help us understand a legacy codebase that had evolved. The person in charge of evaluating the tool loved it, it reverse engineered the entire million+ line C++ codebase in less than 30 seconds! After they were talked into buying it and actual devs tried to use it, we found that it really just took those 30 seconds to fail to parse 95+% of the codebase. The error reporting was so bad the evaluator hadn't even figured out that it failed. (I'm lookin' at you, kid!) It only took us a year and a half to get around to dropping our licenses for that. See? Agile!
    • Domain-specific languages - They're probably used somewhere, though not by myself.
    • Requirement Specification (How?) - A product manager performs some voodoo and invents them. Sometimes they may even talk with customers about them! If you're really lucky, they'll even understand the difference between a use case and a requirement. Don't count on it, though. We don't really do use cases.
    • Continous Integration - No way. It's far more exciting when everything breaks at once.
    • Code-Coverage Tools - Someone once put a blankey on the source repository server in the cold, cold server room. Does that count?
    • Aenemic Domain Model - In all seriousness, I've never even heard of this before.
    • Communication (Wiki, Mail, IM, Mailinglists, other documents) - Memos. Lotus Notes doesn't do "e-mail". Bunch of newfangled rubbish.
    • Effort estimates - Not really. In my organization, Estimates are code for targets.. The due date for a project is locked in during the first of the project's 5 "agile" phases of waterfall development. Those due dates are called "ballpark estimates" but really mean "ship dates."
    • Team size - Runs the gamut, based on product. We have teams as small as four and as big as fifteen if you include managers.
    • Meetings - Not bad if you're relatively junior and aren't working on more than one or two products. I'm only required to attend 2-3 1-hour meetings per week.
    • Code metrics - No.
    • Static code analysis - Theoretically for .Net b/c FxCop is built in and it's use is mandated by our standard, but really, no. Nobody checks it b/c there are never any code reviews. Just the occasional quality audit (aka, paper-trail/blame audit) to make sure we don't lose whatever this year's certification is.
    • Bug tracking - Yes, but only for customer-reported problems. Developers are not allowed to submit discovered bugs against a product they're working on b/c that's not being a "team player." (My boss' boss explained this to me in great detail when I made that mistake. I'm now friendly with a particular customer who's willing to "discover" bugs that I might "accidentally" mention in the course of other support-related communication.)

    As far as big, corporate dev't goes, there's a lot worse out there. Given where I live, and the lack of high-tech jobs in the area, I'm actually pretty lucky to have a gig at all. Doesn't mean I have to like the way things are, though. It just takes a lot of time and constant pressure to even try to influence an established corporate culture.

    But if they get sick of my attempts to change the culture and fire me, well, I don't think I'd cry myself to sleep that night.