Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I am one of two programmers at a small software firm with VERY non-technical owners ("what's a 'browser'" - seriously asked last week).</p> <p>The advantage is that I can choose for myself on most of these points.</p> <p>Test-Driven-Development - Our owner had a bad experience or something. Mention testing in the wrong way and I'd swear she's acting out of PTSD.</p> <p>Domain-Driven-Design - Yep.</p> <p>Model-Driven-Design/Architecture - Yep.</p> <p>Do you test? - Nope. Testing falls on the sales &amp; support staff and the owners. So nothing gets tested much once it leaves my dev machine.</p> <p>Unit Testing - If I got caught doing it I might get fired. And its seriously the only thing that could get me fired.</p> <p>Integration Testing - See "Do you test?"</p> <p>Acceptance Testing - Well, we have to deploy it sometime, right?</p> <p>Code Reviews - No one else would understand it. I've seen everyone elses. Wish I hadn't.</p> <p>Innovative Technologies (Spring, Hibernate, Wicket, JSF, WS, REST, ...) - Yep. But I get flak for it. I'm the "kid" who doesn't know anything that wasn't invented in the last ten years (despite being 30 and having "Readings in Database Systems" on my desk).</p> <p>Agile - I don't waterfall. But I don't really Agile, either.</p> <p>Pair Programming - You don't want to try to talk to the other "programmer" that works at our company.</p> <p>UML - Nope. But I draw boxes with identifiers in them sometimes on my whiteboard. The bosses like that. Good thing they're not more technically inclined, or I'd probably see more boxes.</p> <p>Domain-specific languages - Nope.</p> <p>Requirement Specification (How?) - Nope.</p> <p>Continous Integration - Nope.</p> <p>Code-Coverage Tools - Nope.</p> <p>Aenemic Domain Model - Yep. Tried it. Most of my situations I don't like it for and don't use it.</p> <p>Communication (Wiki, Mail, IM, Mailinglists, other documents) - Tried, couldn't get coworker buy-in. Our MediaWiki install still has the default logo graphic.</p> <p>Effort estimates - We have to estimate how long every job will take in hours. That is what the client gets billed. And that is what we are expected to spend on the project. We even do this when we are looking at new clients and developing new apps from scratch, as well as when we do bug fixes (yeah, we charge clients for that), feature additions, etc.</p> <p>Team size - 1. And let me say this is not a good way to work. It is much better to be able to bounce ideas of other capable programmers in real time.</p> <p>Meetings - few hours worth a week, sometimes double that and rarely less than that. Half the meetings I do are with clients, have are totally internal.</p> <p>Code metrics - Nope.</p> <p>Static code analysis - Nope.</p> <p>Bug tracking - Not as much as I should.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload