Pros
1. Do you use source control? Yes, Git and Github. 2. Can you make a build in one step? Yes. 3. Do you make daily builds? Yes. 4. Do you have a bug database? Yes, VersionOne. Items aren’t always filled out though (expected vs actual behavior, steps to reproduce a bug), which really hurts the tool’s usefulness. 8. Do programmers have quiet working conditions? Yes! Non-cubicle offices each have 2-3 developers, with doors than can be shut in extreme cases. Also, you are tied to the office you were given, so working closely together on projects can be tough. 10. Do you have testers? Yes, but not 1 for every 3 programmers. They’re very good at what they do, but there are too few and their time is often used for other business purposes. 11. Do new candidates write code during their interview? Yes.
Cons
5. Do you fix bugs before writing new code? No. There isn’t enough time. The main product is old, and the internal APIs relied on by all features do not support new functionality and need to be updated, but this is often ignored in order to make deadlines. This debt is often not paid post-release, and the resulting bugs are ignored until met with a serious complaint that might result in a lost sale. Management has tried putting together teams dedicated to only solving bugs, but even those attempts are rushed in order to meet deadlines. 6. Do you have an up-to-date schedule? No. We do have a schedule, but it isn’t up to date enough to reflect what will make a release. Requirements change frequently (as they should when new information surfaces!), but the resulting change in the timeline is not always reflected in the schedule. When the schedule is created, most of the items are considered of critical importance. When requirements are updated and the feature will now take two sprints instead of one, overtime is required instead of having unimportant features cut. 7. Do you have a spec? Sort of. We have per-feature requirements, but they don’t always reflect the final product. In theory, this is fine; we want to be agile so we write a spec and send it to development, and they come back with questions and refinements. In practice, there isn’t enough time to be this flexible, so code is written to spec, and the spec changes later, with the expectation that the deadline won’t change. 9. Do you use the best tools money can buy? No. My workstation couldn’t support the software tools we used, and was never updated. Hardware tools like ergonomic keyboards and mice are strictly bring-your-own. Wide-screen monitors are not accessible to everyone, and tools like [$50 sticks of] RAM require metrics gathering on the scale of hundreds of dollars worth of developer time to prove their worth before purchasing. The primary software tools are also old (C++ Builder, Oracle databases), although that’s mainly due to supporting legacy code. Running old software on old computers is not ideal, and compiling takes 15 to 45 minutes, rather than the 15 seconds mentioned in Joel’s article. Enough time is not given to deal with this infrastructure debt. 12. Do you do hallway usability testing? It’s not common practice, but not unheard of. Mostly there just isn’t enough time for usability testing.