StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<ul> <li>Test-Driven-Development: no. </li> <li>Domain-Driven-Design: no</li> <li>Model-Driven-Design/Architecture: we do start with models for our apps</li> <li>Do you test? yes. Sometimes I'm the only person who tests my stuff. I hate this.</li> <li>Unit Testing - no. This is a lacking area in my skillset I consider high priority to rememdy.</li> <li>Integration Testing - no</li> <li>Acceptance Testing - sometimes. Tough to get the users to go through with it, even with threats from On High.</li> <li>Code Reviews - no. We have discussed doing it but never do in the end. I'm frustrated about this.</li> <li>Innovative Technologies - no</li> <li>Agile - we're mildly agile, though not precisely through a pre-meditated effort</li> <li>Pair Programming - no</li> <li>UML - as little as we need to, but we do model (we're more deliberately agile here).</li> <li>Domain-specific languages - no</li> <li>Requirement Specification (How?) - we do. My group is sometimes primarily responsible for requirements gathering. We are typically assisted by a Biz Analyst now but that wasn't always so. The Veep sometimes hands us requirements that come from I don't know where. Sometimes they're old things that were never done but had been planned ages ago. typically gathered requirements are placed into a Word document reviewed by the primary users as well as my team, the Biz Analyst, and the Veep.</li> <li>Continous Integration - nope</li> <li>Code-Coverage Tools - no</li> <li>Aenemic Domain Model - I'm not familiar with his, but no.</li> <li>Communication (Wiki, Mail, IM, Mailinglists, other documents) - just email and face to face. I broached this subject recently because we need to do something more, a wiki preferrably. It was placed on the back burner.</li> <li>Effort estimates - yes, but we don't make any attempt to really track them. This is another area where I am lacking.</li> <li>Team size - 3, myself included ( Director <- Team Leader <- Me).</li> <li>Meetings - we meet once a week, though not always. Boss usually checks in at least a few times a week individually. Larger group meetings take place sporadically. And of course we schedule meetings to hash out project requirements as necessary.</li> <li>Code metrics - nope</li> <li>Static code analysis - nope</li> <li>Bug tracking - we log errors. that's pretty much our bug tracking.</li> </ul> <p>That's it. We have areas I feel like we could improve on.</p> <p>Update:</p> <p>We lost our business analyst to a large layoff a couple of weeks after I posted this (early November 08). I've since implemented ELMAH in an existing application <em>and</em> a more recently developed one to assist in bug tracking (we also log to a database) and I love it for the ease of use, the features, and the ability to catch exceptions we aren't catching (which is largely unused, but still nice coverage to have). I'm still poking around with Unit Testing on my own - I really need to pick up the pace there (I also want to learn MVC but I mostly poke around with that too).</p> <p>We're desinging a new application right now, and I'm doing a mock DB schema (which will get some basic diagrams) for 3 of the 6 modules (Team Leader is working on the other 3). I'm not looking forward to it, since this will be developed in tandem by the 3 of us (2 modules each) using IronSpeed Designer (6.1). There are things IronSpeed will do for me that I like, but it's not the only way to do these things quickly, and it does some things I don't care for.</p> <p>Nothing else has changed.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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