Submitted by Bob Walsh on Thu, 2006-07-20 13:12.
If you’re going to successfully fire up your micro-ISV, you need to fire your old ideas about software development, be they UML, RUP, agile, SCRUM, extreme or none: they fit like shoes on fish.
Every single methodology for developing software I’ve heard of in over 20 years in this business assumes you’re part of some vast team of programmers, never a programmer working alone. What’s more, each and every existing software development process assumes someone is going to hand you a nice gift-wrapped definition of the problem you’re going to solve via code. That is exactly what won’t happen when it comes to developing a micro-ISV app or web site.
Today’s software design theories are like using a power drill as an ear cleaner - they can be used, but it’s not a good idea. We need a better approach, one based in the reality of one or maybe two programmers who must also define the problem and its solution and who want to do so before their savings run out.
Don’t underestimate just how hard defining the problem domain is, or just how difficult it is to nail down in the absence of actual customers who will tell you what they want. Unless you plan to take a few years unpaid leave from your life to do intensive market research, endless focus groups and surveys, at best you are only going to have a very approximate idea of who is going to be using your software how to solve exactly which problem in what precise way at least all the way through to your public beta.
Submitted by Bob Walsh on Fri, 2006-07-14 07:04.
If you've not been bitten by the Virtual Machine bug yet, it's time to give virtualization, and especially VMware your attention. VMware is out to change a few things in this world, one being how servers serve and the other how developers develop.
Submitted by Rusty Divine on Mon, 2005-11-21 00:14.
The final installment; part six of a series of storied experiences on a small project at a large consulting company in the Pacific Northwest.
Six weeks go by quickly, and the project is complete. Now it's time to take a look back to see what we can learn about what went well and what did not.
Submitted by Rusty Divine on Mon, 2005-11-07 15:00.
Part four of a series of storied experiences on a small project at a large consulting company in the Pacific Northwest.
It was Monday, and I was finally starting to feel at peace with my job and personal life. Friday's confrontation with Robert ended amiable enough with an agreement that we were basically on the same page; the problem was that we didn't know each other well enough yet for trust and understanding to develop. Even the confrontation started building our understanding of each other and brining us closer together as a team instead of driving a wedge between us.
Submitted by Caleb Tennis on Tue, 2005-10-04 08:58.
I've followed the concepts of Extreme Programming now for a while, but I've never fully bought into it. Here's why.
My programming experience, outside of some contributions to open source projects, has been for internal software projects only. That said, it's important to make sure the quality of said programs is just as high as anything a customer would be using - in this case, my customers are also my co-workers.
Submitted by Keith Casey on Tue, 2005-09-27 09:05.
Since I've been talking about Unit Testing quite a bit recently, I thought I'd offer up a review on a book I read a while back. I thought it was a solid roundup of both the principles and the tools used to support Extreme Programming in Java. Overall, I'd give it a 9/10 and I deduct a point solely due to the fact that since it details the usage of numerous Open Source projects, it's halflife could be very short. Regardless, this is more than enough to get you started and will teach you the basics to be able to do even more interesting things.
Just to make this clear right off the bat, if you're not working in Java, only pages 11-27 are going to be of any use. These pages go over the different pillars that make up Extreme Programming (XP). Whether you're using XP or not, you can pick and choose the pillars you need and customize them to your project pretty easily. The principles are: Pair Coding, Unit Testing, Refactoring, Iterative/Minimal Upfront Design, and Regular Builds. I have yet to see a project that cannot benefit from having Unit Testing and Regular Builds in place. These two items serve as a great safety net for current and future development efforts by detecting errors soon after insertion.