My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
Last week I posted about why software developers should care about process, and how they can improve themselves by doing so. In the comments, I promised to give a review of what I'm doing that seems to be working for me. So here they are - the bits and pieces that work for me. Also included are new things we've decided to try, along with some notes about what I'd like to attempt in the future.

Preproject Considerations
Most of our business comes through referrals or new projects from existing customers. Out of those, we try only to accept referrals or repeat business from the "good clients," believing their friends will be similarly low maintenance, high value, and most importantly, great to work with.

We have tried the RFP circuit in the past, and recently considered going at it again. However, after a review of our experiences with it, we felt that unless you are the cause of the RFP being initiated, you have a subatomically small chance of being selected for the project (we've been on both ends of that one). Since it typically takes incredible effort to craft a response, it just seems like a waste of hours to pursue.

On the other hand, we are considering creating a default template and using minimal customization to put out for future RFPs, and even then, only considering ones that have a very detailed scope, to minimize our effort on the proposal even further.

We're also trying to move ourselves into the repeatable solutions space - something that really takes the cheap manufacturing ability we have in software - copying bits from one piece of hardware storage to another - and puts it to good use.

Finally, I'm very interested to hear how some of you in the small software business world bring in business. I know we're technically competitors and all, but really, how can you compete with this?

The Software Development Life Cycle
I won't bother you by giving a "phase" by phase analysis here. Part of that is because I'm not sure if we do all the phases, or if we're just so flexible and have such short iterations the phases seem to bleed together. (Nor do I want to spend the time to figure out which category what each thing belongs in.) Depending on the project, it could be either. Instead, I'll bore you with what we do pretty much every time:

Marker for a whiteboard At the start of a project, we sit down with client and take requirements. There's nothing fancy here. I'm the coder and I get involved - we've found that it's a ridiculous waste of time to pass my questions through a mediator and wait two weeks to get an answer. Instead, we take some paper or cards and pen, and dry erase markers for the whiteboard. We talk through of what the system should do at a high level, and make notes of it.

We try to list every feature in terms of the users who will perform it and it's reason for existence. If that's unknown, at least we know the feature, even if we don't know who will get to use it or why it's needed. All of this basically gives us our "use cases," without a lot of the formality.

I should also note that, we also do the formal bit if the need is there, or if the client wants to work that way. But those meetings can easily get boring, and when no one wants to be there, it's not an incredibly productive environment. If we're talking about doing the project in Rails or ColdFusion, it often takes me longer to write a use case than it would to implement the feature and show it to the client for feedback, so you can see why it might be more productive to skip the formality in cases that don't require it.

After we get a list of all the features we can think of, I'll get some rough estimates of points (not hours) of each feature to the client, to give them an idea of the relative costs for each feature. If there is a feature which is something fairly unrelated to anything we've had experience with, we give it the maximum score, or change it to an "investigate point cost," which would be the points we'd need to expend to do some research to get a better estimate of relative effort.

Armed with that knowledge, they can then give me a prioritized list of the features they'd like to see by next Friday when I ask them to pick X number of points for us to work on in the next week. Then we'll discuss in more detail those features they've chosen, to get a better idea of exactly what it is they're asking for.

We repeat that each iteration, adjusting the X number of points the client gets to choose based on what was actually accomplished the previous iteration - if there was spare time, they get a few more points. If we didn't finish, those go on the backlog and the client has fewer points to spend. Normally, we don't have the need for face to face meetings after the initial one, but I prefer to have them if we can. We're just not religious about it.

Whiteboards at this meeting are particularly useful, as most ideas can be illustrated quite quickly, have their picture taken, and be erased when no longer needed. Plus, it lets everyone get involved when we start prioritizing. Notecards are also nice as they swap places with each other with incredible ease.

Within each iteration, we start working immediately. Most of the time, we have one week iterations, unless there are a couple of projects going on - then we'll go on two week iterations, alternating between clients. If the project is relatively stable, we might even do daily releases. On top of that, we'll interface with client daily if they are available that frequently, and if there is something to show.

If the project size warrants it, we (or I) track our progress in consuming points on a burndown chart. This would typically be for anything a month or longer. If you'll be mostly done with a project in a week, I don't see the point in coming up with one of these. You can set up a spreadsheet to do all the calculations and graphing for you, and in doing so you can get a good idea of when the project will actually be finished, not just some random date you pull out of the air.

Structure of a burndown chart

Another thing I try to be adamant about is insisting the client start using the product as soon as it provides some value. This is better for everyone involved. The client can realize ROI sooner and feedback is richer. Without it, the code is not flexed as much. Nor do you get to see what parts work to ease the workload and which go against it as early in the product's life, and that makes changes more difficult. For us, the typical client has been willing to do this, and projects seem to devolve into disaster more readily when they don't.

Finally, every morning we have our daily stand-up meeting. Our company is small enough so that we can talk about company-wide stuff, not just individual projects. Each attendee answers three questions:
  1. What did you do yesterday?
  2. What are you going to do today?
  3. What is holding you back
The meeting is a time-conscious way (15 minutes - you stand so you don't get comfortable) to keep us communicating. Just as importantly, it keeps us accountable to each other, focused on setting goals and getting things done, and removing obstacles that get in our way.

On the code side of things, I try to have unit tests and integration tests for mostly everything. I don't have automated tests for things like games and user interfaces. I haven't seen much detriment from doing it this way, and the tradeoff for learning how to do it doesn't seem worth it at the moment.

I would like to learn how to do it properly and make a more informed decision though. That will likely come when time is not so rare for me. Perhaps when I'm finished with school I'll spend that free time learning the strategies for testing such elements.

Luckily, when I'm working on a ColdFusion project, cfrails is pretty well tested so I get to skip a lot of tests I might otherwise need to write.

By the same token, I don't normally unit test one-off scripts, unless there are obvious test cases I can meet or before doing a final version that would actually change something.

I don't know how to do it in CF, but when I've use continuous integration tools for Java projects it has been helpful. If you have good tests, the CI server will report when someone checks in code that breaks the tests. This means bad code gets checked in less often. If you don't have the tests to back it up, at least you'll feel comfortable knowing the project builds successfully.

For maintenance, we normally don't worry about using a project management tool to track issue. Bugs are fixed as they are reported - show stoppers immediately, less important within the day, and things deemed slight annoyances might take a couple of days. I'd like to formalize our response into an actual policy, though.

Similarly, new requests are typically handled within a couple of days if they are small and I'm not too busy - otherwise I'll give an estimate as to when I can have it done.

With bugs in particular, they are so rare and few in number that I could probably track them in my head. Nevertheless, I mark an email with my "Action Required" tag, and try my best to keep that folder very small. Right now I've overcommitted myself and the folder isn't empty, but there was a time recently that it remained empty on most nights.

In any event, I normally only use project management tools for very large projects or those I inherited for some reason or another.

Summary
If you're a practitioner, you can tell the ideas above are heavily influenced by (when not directly part of) Scrum and Extreme Programming. I wouldn't call what we're doing by either of their names. If you're not familiar with the ideas and they interest you, now you know where to look.

Where would we like to go from here?
One thing that sticks out immediately is client-driven automated testing with Selenium or FIT. I'd also like to work for several months on a team that does it all and does it right, mostly to learn how I might better apply things I've learned, heard of, or yet to be exposed to. What else? That will have to be the subject of another post, as this one's turned into a book.

Thoughts, questions, comments, and criticisms are always welcome below.

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!


Comments
Leave a comment

I've been producing User-Interface and Software Dev projects for about 10 years and generally, I'd suggest more focus on discovering the real unknown and unmet needs of your target users. I would suggest that your process is cluttered by a lot of concern with techno-centric features and use-cases that probably aren't actually used in the end. Try defining the requirements using scenarios rather than use cases.

At the beginning of your process more user research would let you narrow your focus to the 80% use case rather than worrying about all the possible uses; and we'd never advocate concerning ourselves with a feature for which we had not identified a critical function. Just because something can be done doesn't mean it should or that it should even be proposed as an option to the client. Granted, letting the client prioritize is necessary to some degree.

I usually try to be very transparent about the process with clients and tell them up-front that they can save everyone a lot of time and hassle by simply disclosing their approximate budget range as early in the process as possible. We can then focus on delivering the most bang for our clients buck and given our role as consultants, are usually in the best position to define the feature set relative to known budget targets.

I'd also recommend more low-fi prototyping and actual user testing along the way. It can help you to avoid costly mistakes and/or allow you to do some triage if you see scope-busting, rabbit holes lurking in any less-than-tightly-defined requirements/requests.

I wish you much luck and success,
Sam

Posted by Samuel K Ackerman on Nov 27, 2007 at 02:26 AM UTC - 5 hrs

They say that everybody likes kind words. So I've decided to say some to you. I live in a non-English-speaking country and work in IT sphere. We face a big problem with books and other materials to improve our knowledge in our native language. So I was asked to collect (and maybe later translate) some good materials form the WWW.
I found you blog and think it to be a collection of modern and very interesting thoughts. thank and please continue helping us to develop software using the best world practices!

Posted by Belhard on Nov 27, 2007 at 03:18 AM UTC - 5 hrs

@Sam - Thanks for all the advice, I'll certainly take it into consideration on the next project.

One question though - why do you say "I would suggest that your process is cluttered by a lot of concern with techno-centric features and use-cases that probably aren't actually used in the end"?

Thanks also for the kind wishes. =)

@Belhard - Wow. What can I say? I'm humbled. Thanks for the comment.

Posted by Sammy Larbi on Nov 27, 2007 at 06:32 AM UTC - 5 hrs

Hey Sam,

Another thought-provoking post. The thought this one has provoked is that I'd love to be a fly on the wall in a successful feature listing exercise. In my experience the conversation often goes like this:

Architect: Ok, let's list all the features we need
Client: Well, we just need a system that will manage our widgets.
A: OK, what features does that entail?
C: I don't know, you're the architect, you tell me.
or
C: Just one - management of widgets!

Obviously the architect then does a bunch of discovery work, but I've yet to walk out of such a session with a list of features that would mean anything to a development team. In particular, something like 50% of the feature points that the dev team is actually going to work on will be missing. The system won't work without all the unglamorous stuff like logging, reporting, security, archiving, off-line reconciliation - but we won't get any points from the client for it.

In the same vein, I find it hard to imagine asking a client what features they want next week without getting an answer like "Who cares? We just need the whole thing working by June."

So I like the approach, I can see how it plays out for the dev team, just not sure how to get the client to stick to the script.

Jaime

Posted by Jaime Metcher on Nov 27, 2007 at 05:05 PM UTC - 5 hrs

@Jaime - Thanks for the good comments.

Regarding not getting any points allocated to necessary but non-value-adding things like you mentioned, I've done it where we have a list of "must haves" where you allocate points yourself for it (explaining the reasons behind it) and thus reduce the number of points they can combine for a while. Similarly, it might not make sense to talk about doing one feature until another is in place, so you can also enforce temporal relationships, requiring they have some sort of order when needed.

Regarding the "who cares?" syndrome, that is what I'm talking about when I say without customer involvement it can turn into a complete nightmare of a project. You just have to explain to them that you aren't a mind reader and you need their feedback to make sure you the application is meeting their needs and expectations.

Mention the nightmare scenarios that can occur without their direction - if you stray off the path early in the project by just a couple of degrees, by the end you will be unlikely to be anywhere near the intended destination.

If they absolutely refuse to participate, I'm at the point now where I'd probably just politely tell them I don't want to work with them - because that project is almost certainly doomed to failure and that's not good for either of us. At that point they could see I was really serious about this feedback thing, and may choose to reevaluate their position.

As for sticking to the script, that is why frequent, rich communication and feedback is needed. They won't stick to the script, but with regular feedback loops in place, it gets corrected.

Make sense?

Posted by Sammy Larbi on Nov 28, 2007 at 08:35 AM UTC - 5 hrs

@Samuel, I agree that there is value to doing some research upfront otherwise there is a risk that the client says "I want customers to be able to check real time inventory levels", you spend 3 weeks integrating with their ERP system and when the site launches nobody actually uses the feature.

I don't agree with prototyping though. If you've got an efficient enough set of DSLs for describing your apps you should be able to generate an application (or a rough cut thereof) as quickly as you can prototype it. I see creating real working apps and then adding more detail and refinement with each iteration as better then wasting time and effort on throw away artifacts.

@Sam, I'd strongly recommend Trac. It's just a nice lightweight way of keeping track of the bits and pieces and while it isn't designed for reporting, looking back and seeing the bugs/fixes gives you a real feel for where time went. I'm still looking for the ultimate project management solution with nice reporting, time tracing and the kinds of metrics that'd help me to better manage and select clients in the future based upon what is really taking the time (or which would help me to design tools to automate the processes that are taking the time).

@Jaime, It's a matter of what questions you ask and how congruently/credibly you ask them. Occasionally I'll have a client who says "whatever you want just so as X", but then I'll sit them down and explain we can do one of two things. First is I can run him through the screens upfront. It's pretty easy. "User should be able to check order status", so I'm guessing first thing they do is click on my account. They have to log in if not already. Then they see a list of options including "check order status". They click on that and see a list of orders (what info? Order number? Date? Status?). And so on. I typically find that by asking "What's the first thing they see", "what do they click on", "what happens" and then repeating I get the specs. I also make it clear to client that I can build what I'd like to see but then he's going to have to pay for us to build the site twice. Once for what I want and then a second time for what he wants. If he REALLY wants that and is willing to pay for me to build what I'd like to see then I'm more than happy to do that, sending him only the questions I need to understand his business. It'll cost him more, but that's his call!

Posted by Peter Bell on Dec 08, 2007 at 07:28 PM UTC - 5 hrs

Peter - I might give Trac a shot at the next new project we do. For existing customers, I think it will be too hard to get them to switch away from the convenience of sending off an email, and I'm happy with how it works as well, as long as it doesn't get overwhelming - and it has yet to reach that point.

I would like to give Mingle and Basecamp each a try as well. I've used Basecamp for a few minutes, and liked what I saw - but that doesn't really give me the full scope of how it performs in a real project.

Posted by Sammy Larbi on Dec 10, 2007 at 10:51 AM UTC - 5 hrs

Software development indeed needs a more thorough planning before it can be even started. I like your ways on how you make software development work. I'd like to have these as a guide when I start our software development in our company. Thanks

Posted by Mary Dorreen on Oct 15, 2014 at 09:02 AM UTC - 5 hrs

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)
Website

Comment:

Subcribe to this comment thread
Remember my details
Google
Web CodeOdor.com

Me
Picture of me

Topics
.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Resources
Agile Manifesto & Principles
Principles Of OOD
ColdFusion
CFUnit
Ruby
Ruby on Rails
JUnit



RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner