bliki tagged by: team organization
ApplicationBoundary
How do you define the boundary of an application?
CustomerAffinity
When someone is looking at what makes up a top-class enterprise software developer, often the conversation may turn to knowledge of frameworks and languages, or perhaps the ability to understand complicated algorithms and data structures. For me, one of the most important traits in a programmer, or indeed in a development team, is something that I'll call Customer Affinity. This is the interest and closeness that the developers have in the business problem that the software is addressing, and in the people who live in that business world.
28 July 2006
LargeAgileProjects
A common question is whether large projects can be done with agile techniques. After all many agile approaches are designed for smaller projects and the heavyweight ideas that they resist are more needed on bigger projects.
10 May 2003
PairProgrammingMisconceptions
A bunch of common misconceptions about pair-programming.
31 October 2006
PreferFunctionalStaffOrganization
For as long as I've been in software there's been a debate between FunctionalStaffOrganization and TechnicalStaffOrganization. The debate occurs within project teams, and across whole IT organizations. It's a constant debate because both sides have good logical arguments to support them, and there's no real way to test which has an advantage in practice.
2 August 2004
ServiceCustodian
Let's imagine a pretty world of SOA-happiness where the computing needs of an enterprise are split into many small applications that provide services to each other to allow effective collaboration. One fine morning a consumer service needs some information from a supplier service. The twist is that although the supplier service has the necessary data and processing logic to get this information, it doesn't yet expose that information through a service interface. The supplier has a potential service, but it isn't actually there yet.
14 November 2008
TeamRoom
A common thing you find in agile projects is that the development team sits in a single open team room. It was advocated early on in Extreme Programming and called out as one of primary practices in the second edition. Agilists favor a open team room as it promotes lots of informal and deep communication between people on the team.
14 June 2010
UtilityVsStrategicDichotomy
One of the steady themes I've seen throughout my career is that of the nature and importance of software development. Recently a prospect told one of our salespeople that "software is like sewage pipes, I want it to work reliably and I don't want to know about the details". This is the kind of approach that Nicholas Carr talked about in IT Doesn't Matter. On a contrasting note we've done work for many businesses where IT has been a clearer strategic enabler to their business, allowing them to enter new markets or significantly increase their market share. So is IT a utility, like sewage pipes, or a strategic asset?
29 July 2010
CodeOwnership
There are various schemes of Code Ownership that I've come across. I put them into three broad categories:
12 May 2006
FunctionalStaffOrganization
In general PreferFunctionalStaffOrganization to to TechnicalStaffOrganization
LayProgrammer
I use the term lay programmer to mean someone who is programming without thinking themselves as a programmer. Someone who spends a large part of her day working on spreadsheets is doing programming, often very intense programming. Usually however she won't call herself a programmer, nor think of spending much time learning how to program better.
PreferDesignSkills
Imagine a hiring situation. There's two candidates both with a few years of experience. In the blue corner we have someone with good broad design skills in the style of design that you favor (in my case that would be things like DRY, judicious use of patterns, TDD, communicative code etc, but the actual list isn't important - just that it's what you favor). However she knows nothing of the particular platform technology that you're using. In the red corner we have someone who has little knowledge (or interest) in those issues, but knows your platform really well - edge cases in the language, what libraries are available, fingers move naturally over the tools. Assume all else about them is equal (which it never is except for thought experiments like this) and that your team doesn't have any gaping holes that this candidate might fill. Which one would you prefer?
17 January 2008
SecurityAndDesign
This last week I had the pleasure of wandering around Florida
speaking with Dan Sandlin and David LeBlanc at a series of Microsoft
architecture councils. For those who don't know David LeBlanc
wrote the very popular book Writing Secure
Code
14 June 2003
ShiftingToCodeOwnership
In my recent CodeOwnership post, I described the way in which I think about code ownership issues. Many of my software development friends are extreme programmers, and tend to favor collective code ownership. However these kind of practices aren't absolute and should always be tempered by local considerations. One of my colleagues sent me a note with the following story which I thought was a good indication of when you have to vary your practices, even if you are a strong fan of XP. (As he's talking about his team, he prefers to be anonymous.)
15 May 2006
TechnicalStaffOrganization
Although I generally PreferFunctionalStaffOrganization the arguments in favor of a technical orientation over a FunctionalStaffOrganization cannot be dismissed lightly.