April 2009 Entries

Wrapping up our first pass at Development Project Archetypes we look at a common culprit on brownfield teams. During your first week on the project you’re assigned to have a mentor who has written a large portion of the existing application. While working on your first serious defect in the system, you ask the Possessive Developer about an existing piece of code and suggest refactoring. She looks back at you and states “There’s no reason to change that code. It works just as I want it to.” After explaining its deficiencies, the Possessive Developer is sullen and in a...

For the final few posts in the Development Project Archetypes we'll focus on developers. An incestuous cousin to the Front of the Magazine Architect, this developer is easily distracted by any new technology. Not only will he want to talk about it endlessly, the ‘Oooo…Shiny!’ Developer will simply add the technology to the project without telling anyone. You will find, scattered through the code base, a number of different techniques, tools or frameworks that are used one time and then abandoned. While adding to your technical debt, the ‘Oooo…Shiny!’ Developer is working feverishly to keep adding new entries to...

Still avoiding developers, we continue talking about archetypes... Usually found in the confines of an organization that has heavily silo’d roles and responsibilities, the Enhancing Tester will be assigned responsibility for ensuring the product quality. She believes it is her personal responsibility to question and alter any specifications that were used in creating the software. Since she wasn’t involved at the start of the development cycle, the Enhancing Tester will question the design and requirements only after the development team has passed them on for test. The proposed ‘enhancements’ are usually obscure and with far reaching architectural ramifications. For...

Deviating from the developer sphere, we continue the Development Project Archetypes... A good many application require access to a database. If you’re lucky, you’ll have free rein over the database to make whatever changes you deem necessary. If you’re unlucky, you’ll need to make those changes through an Over-Protective DBA. The Over-Protective DBA protects his database with an iron fist. Requests for changes to a stored procedure go through several iterations to ensure they include the standard corporate header and naming conventions. He also challenges every single piece of code in the procedure to see whether you really...

Another in the Archetypes series... Everyone loves a hero. The PM, the architects and the client relish the long hours he puts into delivering results. When the client is told we don’t have the budget or manpower to add a feature, the hero’s cubicle is his first stop after the meeting. “Old man Baley says we can’t have this. But we NEED it.” The Hero hums and haws and complains how badly the project is being managed, then with a sigh says, “I’ll put it in. But this is the LAST TIME.” The Hero then proceeds to circumvent...

A while back I posted about a small framework that I wrote to make handling of nHibernate Sessions easier in a WCF world.  There were a couple of problems with it and I've spent some time fixing it recently.  The entries on the wiki have been updated to fix problems in the documentation as well. The big changes in the framework were a bug fix that was preventing the commit from being run, moving to the latest version of nHibernate, and making better use of nHibernate transactions.  The svn source code repository is available here.  If you get it and run...

The next post in the Software Development Archetypes series... Every project needs experienced people to improve the odds of succeeding. Skilled developer resources are hard to come by so you’re really excited to be joining a team that has some “Experienced” Developers. But it doesn’t take long on any project to realize that experience is a relative term. When asking for help, the “Experienced” Developer’s questions are often at the same level as some of the junior developers on the team. When he does propose a solution, and has it turned down, he immediately plays the “I have 12...

Another post in the Development Project Archetypes series... Every time that the team attempts to implement a technique, process or technology that will address a project problem and better the team’s ability to deliver to the client, the Skeptic will interject. If it’s unknown to the Skeptic, then he must speak out about his doubt. Often the doubts are small and founded in his complete lack of knowledge. Regardless, he will stand by them vigorously until the project has discussed (at least three times) the situation. The discussion will not, however, satisfy the Skeptic. If he does agree...

Transitioning into the realm of developers, we continue the Development Project Archetypes series... Though you will usually see the Disinterested Developer working diligently whenever you walk by, you also notice she has a well-known social networking site constantly minimized on his desktop. Over time, you see a pattern: social networking tools when no one is thought to be around, development tools when there is. During meetings the Disinterested Developer is looking out the window or checking her mobile phone. She doesn’t engage the rest of the team on a technical level. She answers only when required and delivers the...

Resuming the Development Project Archetypes series... Monday morning and the Ex-Tech PM appears on the edge of the status meeting as an observer to the team’s daily ritual. One by one the developers tell of their current work and its state. As one developer mentions that there will be some design work in his day ahead, the Ex-Tech PM interjects with “We used to do <something> when I was an RPG developer. You should look into doing that too.” The team continues through the standup and when completed the Ex-Tech PM corners the developer to provide more details about...

The next post in the archetypes series... Once a month, every month, she visits the team and blurts out “We should use/do/implement <insert technology of the month here>.” The monthly rhythm of the visits is tied directly to the delivery of the Front of the Magazine Architect’s magazine subscriptions and RSS feed. Anything that is boldly emblazoned across the cover of an IT related periodical becomes that month’s flavour. The Front of the Magazine Architect is another easy one. While they are annoying distractions, her visits will be infrequent and short lived. As quickly as the idea enters...

Another in the archetypes series... This person is one of the most feared by developers around the world. While the team is working to deliver software, he is asking them to write action reports and detailed impact analysis documents and any number of other reports he needs to grease his process and document pacifier. Though able to bend Outlook and Microsoft Project to his will, the simplest of changes, like re-scheduling a recurring meeting, will throw the Process-Heavy PM into a fetal position. It will take him days to recover from the disruption to his carefully scripted master plan...

Continuing the series on archetypes... Beaten down by months of missed deadlines, misunderstood requirements and repeated defects, the Disenfranchised Client has lost all faith in the team’s ability to deliver and is merely going through the motions until the next budget cycle. Because of this and because she pays the bills, she is one of the most dangerous archetypes. To counter her, you’ll need strong social skills to assure her that her needs are being met, though it may be weeks until you see any progress. The best way to deal with a disenfranchised client? Give her working...

The next instalment in the archetypes series... When the project starts the Absentee Client engages the team just long enough to build up some velocity. As soon as he perceives some progress being made, the project is quickly re-prioritized to a much lower level in his calendar. The team will wait days or weeks to hear back from The Absentee Client about the simplest of clarifications. Important meetings will be rescheduled numerous times at his request and when he does attend they will have to be cut short due something else important having come up. One way to...

This is a commonly known archetype in the development world.  Since it's commonly known I figure it's a great place to start this series of posts. Sporadically swooping into meetings with the rest of the team from his namesake home, the Ivory Tower Architect loves to show his mastery of software design. Whether it works in practice or not matters not to him. The rest of the development team is left to implement the grandiose plans handed down from on high, but the Ivory Tower Architect will never work directly on the code himself. Often the designs are overly...

As part of writing our book, Kyle and I have spent some time coming up with archetypes that exist on many of the software projects that we've been on.  Our goal is just to describe what we've seen so that people can better identify them in their journeys.  Of course this had to be written in a dry, sarcastic manner.  I'm going to keep updating this post with the links for the new archetypes as I post the series. Ivory Tower Architect The Absentee Client The Disenfranchised Client...