In many organization I've encountered there is this artificial distinction between the new development group and the maintenance programming group. Why on God's green earth would you want to do such a thing?
Every time the topic comes up I point out that there is only "maintenance" since once you have the first line of code checked in you are now maintaining the system. Probably the only difference between "new development" and "maintenance development" is whether the system is being used in production or not!
A better approach in my opinion is to view all your systems as the software ecosystem for your organization. You now have the common problem of limited resources to change/add features to the ecosystem. The features may or may not be added to systems that already exist. Whether the system already exists is irrelevant to the decision to spend money on that feature.
Organizations that have adopted agile practices eventually notice that there is little or no difference between new functionality, enhancements and bug fixes. If there is a difference it is more a difference of granularity in that some bug fixes are very small while everything else tends to be larger.
The advantage of the ecosystem approach is that your development resources are more of a pool that you can draw from, the stigma of being on the maintenance team doesn't exist, and knowledge can be spread among the team.
Think about it, try it. You might like it.
A.J. found in Executive Leadership this list of the 5 biggest complaints employees have about their bosses:
- Wasting their time
- Micromanaging them
How many of these have to exist before your top talent starts walking out the door? I suspect it somewhat depends on the economy and how interested/vested they are. I suspect, however, that once you hit 3 out of 5 people start walking out the door.
In reflecting on my previous post regarding shared libraries in VSS vs CVS I realized that the end of the post got to the real meat of the matter. Turns out we are using a feature of VSS to help us organize our shared libraries, however, shared libraries really have very little to do with version control (except for released versions of course).
Project references are the main reason you should adopt a single solution or partitioned single solution model wherever possible.
In the Single and Partitioned Solution Systems section:
Use project references wherever possible and aim to minimize the use of file references.
These recommendations are a little simplistic. Surely Microsoft doesn't have a single solution for the entire .NET framework! And they are only building a single product.
Further on they propose an alternative that sounds promising - use a build server and place the shared libraries on a file share. Additionally you can copy the shared libraries locally from time to time to support disconnected development and developer control over when libraries are updated.
This sounds like it will work well as long as you have a build server and all developers map the shared library share to the same drive letter. In fact using a mapped drive letter allows a lot of flexibility in that just by changing the drive letter mapping you can point to the release version, debug version or the local version of the shared libraries since VS.NET stores the absolute path to shared libraries in the project file (in the HintPath attribute).
- William Bartholomew Organising Visual Studio .NET Solutions
- Jeff Gonzalez Solution and Project Organization
- Roy Osherove How to: Creating project groups under a single solution
- Robert W. McLaws Developing Components: Code organization, a technique reexamination and modification
Saw this on StickyMinds today: Bumper Stickers for Testers
- Software Testers: "Depraved minds...Usefully employed."
- Software Testers: We break it because we care.
- A good tester has the heart of a developer...in a jar on the desk.
- Friends don't let friends do capture-replay.
- Trust, But Verify.
- Pertempto ergo sum – I test, therefore I am.
Anyone have any bumper stickers for development, project management, product management, documentation, DBAs, etc?
Via Clarke Ching
In early 2003 Michael Crichton gave a fascinating Caltech Michelin Lecture titled Aliens Cause Global Warming.
He argued that a lot of today’s science is bad science and that bad science is often used to back up good policies.
I've been listening to a number of Pop!Tech speakers via IT Conversations and many of the assertions made by the speakers bothered me, but I couldn't figure out why. This lecture helped me understand some of what was bothering me.
Check out Clarke Ching's new book project Rolling Rocks Downhill. The purpose of the book is to help people – customers, managers, workers (and even their families) – who work on traditionally managed software development projects to find a better way.
Personally I enjoy a fictionalized look at my industry from time to time.
The Macau Productivity Center has released a PDF version of their book Essential Skills for Agile Development. It covers the basic development skills necessary for a programmer on an agile (XP specifically) team.
Chapters begin with short descriptions of the topic and then have many exercises focusing on code.For instance chapter 4 (on refactoring) has 5 pages of descriptive text and 34 pages of exercises and solutions. Because of the short chapter length only light coverage is given to each topic. However, the author states up front that he is using the 80/20 rule and that the reader will have to look elsewhere for a more detailed treatment.
Table of Contents:
Chapter 1. Removing duplicate code
Chapter 2. Turning comments into code
Chapter 3. Removing code smells
Chapter 4. Keeping code fit
Chapter 5. Take care to inherit
Chapter 6. Handling inappropriate references
Chapter 7. Separate database, user interface and domain logic
Chapter 8. Managing software projects with user stories
Chapter 9. OO design with CRC cards
Chapter 10. Acceptance test
Chapter 11. How to acceptance test a user interface
Chapter 12. Unit test
Chapter 13. Test driven development
Chapter 14. Team development with CVS
Chapter 15. Essential skills for communications
Chapter 16. Pair programming
The book layout is a little odd for one concentrating on agile development since it leaves many of the core topics to the end of the book (unit tests are in chapter 12).
This book was written in Macau (a Chinese Special Administrative Region in Guangdong province) and seems to have a assumption that the exercises will be done by the reader. I'm not sure that the Western reader will typically do the exercises. I'd like to see the book broken into the main text and a separate workbook or at least make the exercises shorter by focusing on 2-3 that really drive the point home. This could make the book around 150 pages rather than the daunting 427. Additionally the text is a little stilted probably because English is not the author's primary language.
Overall it is probably a pretty good use of time for the experienced agilist to skim the narrative portions of the book and maybe have new to agile developers read it.
I went to see The Incredibles (great film by the way) the other day at a theater I hadn’t been in before and I was struck by the difference as soon as I walked in the door. You buy your tickets the normal way (or online), but the snack bar has been changed into a mini-supermarket/deli. The great feature about this change is I can pick up all the food I want without waiting in line (except popcorn and some deli items). You pay at a supermarket style checkout stand. This is great since now you don’t have to wait for the guy who needs to buy popcorn for the 6 kids he has with him (oh and by the way they ran out of popcorn and have to pop more) when I just want a soda.
This is a great application of the Theory of Constraints (ToC). ToC in its simplest form is examining a system for the largest constraint and then making that constraint go away. This exposes a new constraint and you keep repeating. I don’t claim to be an expert in TOC, but rather a beginning student. I do find it interesting that once you start thinking about systems this way your world view changes in a way that is similar to getting object orientation, test driven development, self managing teams, etc.