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

since i've started first job professional software developer 2 years ago, i've read many articles commonly accepted methodologies (e.g. scrum, xp), technologies (e.g. ejb, spring), techniques (e.g. tdd, code reviews), tools (bug tracking, wikis) , on in software companies.

for many of these i've found @ our company doesn't use them , ask myself why. doing wrong or merely these articles i've read not telling it's in real world? these articles more academic?

so, please tell me it's @ company. tell regarding software development. here suggestions (in order come mind). tell @ least if or not, or give short comment:

• test-driven-development
• domain-driven-design
• model-driven-design/architecture
• do 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: want know do, not or think should do.

• test-driven-development - no way.
• domain-driven-design - what's design?
• model-driven-design/architecture - what's design? have architecture team. 1 exception (the junior architect), couldn't code way out of paper bag. they're sure @ drawing boxes lines, though! , establishing crappy, worthless, over-generic , useless standards. (the old opc stuff ok, ua standard has been "done next month" last 4 years or so.)
• do test? - yep, have dedicated test team. there's 1 tester every 10-12 devs. they're swamped. ask me if test well.
• unit testing - informal/up developer. when schedule i'm given allows it.
• integration testing - yes. one's necessary given suite of products develop , support.
• acceptance testing - yes, contract-y work only.
• code reviews - pay lip service, never ever it.
• innovative technologies (spring, hibernate, wicket, jsf, ws, rest, ...) - taking new dependencies frowned upon. boost never adopted, e.g. have had luck getting newer versions of .net, though, if typically 2 years or behind curve.
• agile - no. management claims want "agile," though don't exhibit barest understanding of is. modified our process higher priority tasks spec'd , implemented with... (wait it) higher priority! management tells me our new "agile" process. still smells, walks, , quacks waterfall though.
• pair programming - no way! pay two people work of one? next you'll suggesting developers should waste time on nonsense designs , code reviews. dogs, cats, living together!
• uml - no. got uml tool once understand legacy codebase had evolved. person in charge of evaluating tool loved it, reverse engineered entire million+ line c++ codebase in less 30 seconds! after talked buying , actual devs tried use it, found took 30 seconds fail parse 95+% of codebase. error reporting bad evaluator hadn't figured out failed. (i'm lookin' @ you, kid!) took year , half around dropping our licenses that. see? agile!
• domain-specific languages - they're used somewhere, though not myself.
• requirement specification (how?) - product manager performs voodoo , invents them. may talk customers them! if you're lucky, they'll understand difference between use case , requirement. don't count on it, though. don't use cases.
• continous integration - no way. it's far more exciting when breaks @ once.
• code-coverage tools - once put blankey on source repository server in cold, cold server room. count?
• aenemic domain model - in seriousness, i've never heard of 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 organization, estimates code targets.. due date project locked in during first of project's 5 "agile" phases of waterfall development. due dates called "ballpark estimates" mean "ship dates."
• team size - runs gamut, based on product. have teams small 4 , big fifteen if include managers.
• meetings - not bad if you're relatively junior , aren't working on more 1 or 2 products. i'm required attend 2-3 1-hour meetings per week.
• code metrics - no.
• static code analysis - theoretically .net b/c fxcop built in , it's use mandated our standard, really, no. nobody checks b/c there never code reviews. occasional quality audit (aka, paper-trail/blame audit) make sure don't lose whatever year's certification is.
• bug tracking - yes, customer-reported problems. developers not allowed submit discovered bugs against product they're working on b/c that's not being "team player." (my boss' boss explained me in great detail when made that mistake. i'm friendly particular customer who's willing "discover" bugs might "accidentally" mention in course of other support-related communication.)

as far big, corporate dev't goes, there's lot worse out there. given live, , lack of high-tech jobs in area, i'm pretty lucky have gig @ all. doesn't mean have way things are, though. takes lot of time , constant pressure try influence established corporate culture.

but if sick of attempts change culture , fire me, well, don't think i'd cry myself sleep night.