Tuesday, August 31, 2004

I'm poor but doing OK

Some time ago I cut the amount I pay myself down to $325 a week. That's $325 Australian which is about $220 US, £125 or €181 by today's exchange rates. I did that well before I quit my day job to get used to getting by on much less money. It took some adjusting but at the time I left my day job I was within striking distance of my meeting my budget, over spending by an average of only $70 per week.

Checking the figures today for the past 8 weeks (July-August) I come in under budget by an average of $3 per week.

Weekly Spending AveragesMay-JuneJuly-AugustBudget
Rent$135$135$135
Groceries$63$55$55
Trains, buses and taxis$21$22$30
Bank fees and interest$13$3$0
Miscellaneous$162$81$90
Telephone$0$10$10
Gas and Electricity$0$16$5
Total$394$322$325

8 weeks at an average of $3 under budget per week. That's a whole $24 I have left over to hit the town with. Look out ladies, big spender coming through.

Seriously though, I think I've done a pretty good job with this both in setting my budget at the correct levels and sticking to it. My plan to go to the ATM only once each week, straight after pay day, has been working well. I withdraw the whole $90 that's set aside for miscellaneous expenses and don't go back to the ATM until the following week. With the cash actually sitting in your wallet you're much more conscious of how much you've actually got left. When it's in your account there's a tendency to forget how much you've spent for the week and keep going back to the ATM whenever you run out of cash.

How's it been living on a reduced income?

It hasn't been too bad. I've gone back to some leisure activities which either cost nothing or cost very little. Things like bike riding, squash, playing music, and going to the gym. There's actually a surprising amount of things you can do without spending a lot of money.

I do miss being able to buy CDs on impulse though and it can be a bit awkward when going out with friends if my money is running low.

Some aspects of being poor are really quite beneficial. I think I've only had junk food once in the past 8 weeks. Whenever I pass a fast food shop and I'm tempted I start to think about how many proper meals I could prepare for the same amount of money. It's about 8 breakfasts, 5 lunches or 2 dinners for the trainspotters out there.

I haven't become a complete penny pincher just yet though. I still shop at the more expensive supermarket (I can't face learning another supermarket layout) and I'll go to the movies any night not just half-price Tuesdays. I enjoy spending my $90 when I'm out with friends and try to make sure I spend it all each week.

I guess it's all a question of balance and keeping my priorities straight. Having to act miserly during the week isn't fun, but it stretches my limited business cash reserves further and means that once or twice a week I can afford to splash out just a little with friends. When you're spending most of your time working alone, keeping that interaction happening becomes more important than you first realise.

Sunday, August 29, 2004

Feature Driven Development

In my last post I said that I would be building Sydney using an agile influenced code and fix methodology. Of those agile influences, Feature Driven Development (FDD) is likely to be the strongest. FDD isn't particularly well known so I've devoted this post to describing it.

This isn't the methodology I'll be using for Sydney, but it is where I'm going to steal a lot of ideas from.

What is Feature Driven Development?

From the book "A Practical Guide to Feature Driven Development", here's the authors guide to FDD in four sentences.

FDD starts with the creation of a domain object model in collaboration with Domain Experts. Using information from the modeling activity and from any other requirements activities that have taken place, the developers go on to create a features list. Then a rough plan is drawn up and responsibilities are assigned. Now we are ready to take small groups of features through a design and build iteration that lasts no longer than two weeks for each group and is often much shorter - sometimes only a matter of hours - repeating this process until there are no more features.

FDD is an agile software development methodology created by Jeff DeLuca of Nebulon Software. Like most modern methodologies it is based around iterative rather than waterfall development. FDD emphasises customer involvement and provides excellent transparency to both the developers and the customers through simple yet effective progress reporting procedures. Unlike some other agile methodologies FDD does incorporate initial design efforts and is designed to be easily scaled upwards to incorporate large development teams.

FDD is composed of 5 processes, with each process able to be described in 1-2 pages. The whole FDD methodology can be downloaded and printed out in just a few pages.

The 5 processes

  1. Develop an overall model
    • Form the modeling team
    • Domain walk-through
    • Study documents
    • Develop the model
    • Refine the overall object model
    • Write model notes
  2. Build a features list
    • Form the features list team
    • Build features list
  3. Plan by feature
    • Form the planning team
    • Determine the development sequence
    • Assign business activities to Chief Programmers
    • Assign classes to developers
  4. Design by feature - Start of iteration for one or more features
    • Form feature team
    • Domain walk-through
    • Study the referenced documents
    • Develop the sequence diagrams
    • Refine the object model
    • Write class and method prologues
    • Design inspection
  5. Build by feature - When features completed return to process 4
    • Implement classes and methods
    • Code inspection
    • Unit test
    • Promote to the build

Some FDD curiosities you might be interested in

A feature is the basic unit of development and is a task that can be completed within a 2 week timeframe. All features must be expressed in customer valued terms stating an action that a customer will perform using the system.

The object model is designed in the without first writing requirements documents and with the customers present and directly involved in modeling process.

There are one or more Chief Programmers who for each iteration assemble a different team of junior developers.

Each class is owned by a particular developer and only they are permitted to work on that class.

Code inspections and unit tests are used to ensure the ongoing quality of the system.

With FDD it is possible to give an accurate statement of your progress as a percentage. This is because FDD doesn't ask developers how much they've completed, instead it tells them how much they've completed.

More information

Your first stop for more information on FDD is the FDD website at Nebulon Software and the FDD community site both maintained by Jeff DeLuca. The online FDD community is reasonably active and the signal to noise ratio is generally quite high.

In regards to published material it isn't necessary to read a thick book to follow FDD and for some time there was no book dedicated to FDD at all. Eventually of course such a book was written, "A Practical Guide to Feature Driven Development" by Stephen Palmer and John Felsing, who have worked with the creator of FDD, Jeff DeLuca, on past projects.

I have mixed feelings about this book. On the one hand it is a valuable source of information providing answers to the many questions that are raised by the original 5 processes document. On the other hand even though it's not a particularly long book I feel that provides too much information and doesn't present it in a particularly well organised fashion. It's a book that I've tried to read right through several times but each time have failed to finish. Maybe it's just me, I'm not sure. Until something better comes along though, I do recommend you buy a copy if you'd like to learn more about FDD.

There is one more published source of information on FDD available that I'm aware of. There is a book by Peter Coad called "Java Modeling in Colour". The last chapter in that book is an explanation of FDD written by Jeff DeLuca. This book is harder to find these days, but you can download that particular chapter as a PDF file.

Friday, August 20, 2004

Why I'm not agile this time

Advice is often given to take what works for you from a software development methodology and to discard what doesn't. In my opinion this advice is dangerous in respect to implementing agile methodologies. The temptation is simply too great to take the parts you like such as little or no design upfront and ignore the parts you may not like or find too difficult such as pair programming, test driven development, code inspections or continuous integration. These methodologies are not as yet understood well enough for the nonexperienced practitioner to be able to make value judgments on their component parts. If a team chooses to ignore certain practices of an agile methodology then I believe they should not claim to be following that methodology.

It's for this reason that I cannot claim to be following an agile methodology in the development of Sydney, despite announcing my agile leanings in my last post. To the best of my knowledge there are no agile methodologies that do not rely on a team of two or more developers. Whether it is pair programming in Extreme Programming, code inspections in Feature Driven Development or the daily team meetings in Scrum (ever heard of a one-man scrum pack?) a team of one simply does not provide the necessary checks and balances to be able to claim to be running an agile development project.

As long as I am running a one-man operation at best all I can claim is to be running an agile influenced, code and fix project. Either that or I bite the bullet and adopt a heavyweight methodology like RUP, and I'm far too lazy to do that. So at this stage my non agile development process will be strongly based upon Feature Driven Development and will also borrow several practices from Extreme Programming. I'll try to make it resemble these processes as much as possible in the hope that in the future should my operation grow beyond just me to be a team effort it will be easy to properly adopt an agile process.

I'll provide more details about my agile influenced, code and fix methodology soon. In particular I'll go into more detail about Feature Driven Development as it is not as well known as Extreme Programming.

Why I like agile software development

I'm a fan of agile software development methodologies, it says so on my business card. I believe they represent a better way to write software than more traditional heavyweight methods for a lot of projects. Another reason I have to admit I'm such a fan is because I've inherently a lazy man. Agile methodologies don't require you to write enormous requirements and specifications documents before you start coding which is something I'm quite happy to live without. Judging by the recent popularity of agile methodologies there are plenty of other lazy people out there who are just as happy about that as I am.

Some of them are even happier about that than I am, mainly because they think being agile means having no process at all. They think it's a green light to just hack away at code until it works giving minimal or no thought to requirements gathering, design, testing, and overall code quality.

Why do they think that? Well one reason is because when you read some of the agile methodology books that is the message you can come away with. That is, it's the message you can come away with if you choose to ignore all the high discipline practices that are also described in those same books.

I have known companies who claimed to practise development under the agile banner. In actually they were practising plain old seat of the pants code and fix development. They kidded themselves into believing they were practising agile development simply because they had no formal requirements or design specifications. While a lack of formal requirements and design specifications can be a characteristic of agile development projects it is also a characteristic of unplanned, undisciplined and chaotic code and fix type projects. The practices that prevent an agile development project from descending into a one of these chaotic code and fix operations are strict adherence to rigorous quality control processes. A project that does not implement these quality control processes is simply not practising agile development.

I can foresee an inevitable backlash against agile methodologies, just as there has been a backlash against heavyweight methodologies. One reason for this backlash will be that the reputation of agile development will have been tarnished by companies such as these who claim to be agile but in reality are following no discernible process. As their "agile" projects continue to fail and come in way over budget, agile methodologies will be unfairly seen as offering no improvement over code and fix development.

Practising an agile methodology is difficult, perhaps as difficult as practising more traditional heavyweight methodologies. In agile development all processes are essential to the final outcome so agile practitioners must maintain a high level of concentration at all times. Quality control processes in agile projects must be strictly adhered to without exception or the project will degrade into a hacking free for all. Several agile methodologies espouse development processes that are contrary to established ways of working such as pair programming where two programmers work at the one computer and test driven development where test cases are written before the actual application code.

If an organisation lacks the discipline to be able to implement a traditional heavyweight methodology then I believe it is questionable whether they will have the discipline to successfully implement an agile methodology.

So if it is as difficult to implement an agile methodology as it is to implement a traditional heavyweight methodology then what is the advantage in going agile?

In my opinion there are two main advantages. The first is that all processes in agile development have a direct influence on the final output of the project. If a process does not move the project closer to its final goal it will be eliminated. Consequently the final goal can be achieved in less time than using a heavier methodology.

The second advantage is the agile philosophy of always meeting customer expectations and accomodating their changing requirements at all phases of the development process. It acknowledges that customers can't possibly know exactly what they want at the commencement of a project. Rather than punish customers for their fuzzy requirements, agile development involves them throughout the development process to ensure that the end result matches their evolving expectations. An agile development team will never hear the words "That's not what I asked for", or "It's what I asked for, but it's not what I want." If they do they simply aren't practising agile development.

Saturday, August 14, 2004

I don't link much

This isn't really a linking blog and I like that. I figure you've already read the latest blogging news of the day on 5 other blogs and there's no reason for me to repeat it here.

Hopefully this helps to keep the signal to noise ratio pretty high. When I post it's because I've got something to say. While I enjoy posting here I don't have the time or the inclination to post every single day. I haven't posted in a while but I have been working on a few posts which you'll start to see shortly.

Enjoyment aside this blog has a greater purpose and to fulfill that purpose I need to build up a reasonable sized readership. By not linking to other blogs though I provide no encouragement for others to link to me and I miss out on the associated site traffic that would bring.

While I prefer a more organic growth as opposed to more manufactured schemes I do think I need to give things here a bit of a kick along. So here's what I'm planning on doing. It's still pretty organic, just with a bit of fertiliser.

Every so often (once a week at the most) I'll post a summary of links on a particular topic. I'll keep it on topic and will only include the best postings I've come across.

I'll add a blog roll to my site. I'm uncertain of their value but they're pretty innocuous and I guess it's nice to acknowledge others. If you have a blog and would like me to take a look at it please leave a comment here with the address.

I might do an occasional review of someone else's blog, pointing out my favourite posts, what I've learnt from them and how I adjusted my plans and behaviour accordingly. Again these will be selected from blogs related to the subject matter here and I'll only review those blogs of those who really do have something original to say.

Lastly I'm going to ask you for a bit of help. If you've been enjoying the journey so far I'd appreciate if you would consider linking to me from your own blog if you have one. I've got some good posts coming up shortly with both business and technical slants. Perhaps if one of them catches your eye you could use it to introduce me to your readers.

I also want to take this opportunity to thank you all for sticking with me up to this point. I appreciate the kind words of encouragement I've received and will be acting on some of your suggestions and requests soon.

Tuesday, August 10, 2004

Together at last

I've been using Together Designer Community Edition from Borland for the past 2 weeks to do some conceptual modeling for Sydney. TDCE is a free download from the Borland website and if you do any sort of work with UML I suggest you start downloading it right now. It's a 60MB download so you'll have plenty of time to read the rest of this post as it comes down.

TDCE is basically a stripped down version of Borland's Together Control Center product. It was originally written by Togethersoft before they were acquired by Borland a few years ago. It started it's life as a modeling tool for Java developers but now supports C# also. I don't know much about the full product but based on this free version if you're working in Java or C# you'd be mad not to pay the ridiculously affordable price of $199 for it. I've been told that Together formerly sold for several thousand dollars and had a very devoted following even at that price.

TDCE is a UML modeling tool only and unlike the full Together product includes no code generation or reverse engineering features. That's fine by me since conceptual modeling is just what I need right now.

I previously used pen and paper or occasionally Visio for conceptual modeling. At these early stages you can't afford to be precious about your model. You're going to have a lot of ideas and most of them are going to be bad. You need something with the freeform creativity of pen and paper, something that lets you screw up the page and throw it away without any sense of regret. If your modeling tool requires you to spend a lot of time making your diagrams nice and neat you'll be reluctant to change or redo them. You may find yourself persevering with a bad design because it's just too much work to redraw the diagrams.

TDCE is the first program I've used where drawing a class diagram on screen is almost as easy as drawing it on paper. It's automatic layout features are good enough that you can just slap down some classes, link them with some associations and generalizations and then get TDCE to lay them out nicely for you.

When it comes to drawing a sequence diagram TDCE is easier than drawing it on paper. While there are a few more clicks involved than what I'd like when adding a message/method this is more than balanced out by the ease with which the diagram can be adjusted after the fact. Sequence diagrams are always needing to be adjusted and with the tools I've used in the past you may as well throw the whole diagram away and redo it. TDCE makes it very simple to alter an existing diagram by intelligently adjusting the position of existing messages/methods as you add or remove other parts of the diagram.

I haven't come anywhere near to investigating the full potential of the program but for these reasons alone I've made it an essential part of my toolkit when designing a new object oriented system.

Here's a few things I like about TDCE.

  • Nice interface
  • Good keyboard shortcuts
  • Intelligent automatic layout functions
  • Able to type class names as method return types rather than having to select them from a list.
  • Changes to an identifier are reflected in all diagrams automatically
  • UML 1.4 and UML 2 support
  • Flexible project structure with a project made up of a directory and it's subdirectories. Takes a little getting used to but means you can share diagrams between different projects.

And here's what's not so good.

  • No print function - you can save to various image formats though.
  • Memory hog - you need 512MB minimum.
  • No useful way to import existing Delphi code
  • Java centric terminology
  • Design objects live on their original diagram and can be deleted from the whole project if removed from that original diagram.
  • Type names for objects in sequence diagrams are fully qualified types and hence way too long
  • No sequence diagrams in UML 2 support (yet)

Here's hoping that Borland keeps updating this free version. I guess I could always buy the full version at for $199 but it's hard to justify it when I'm not working in Java or C# at this time.

Friday, August 06, 2004

We have another customer

Earlier in the week I received a call from a second TWYC customer. He was having problems with his computer not turning on. It sounded like faulty hardware, which I prefer not to deal with, but he lived literally in the next building so I went and had a look.

There wasn't much I could do onsite so I took it to the shop down the road. I'd spoken to them a few weeks ago about my plans to set up a troubleshooting business in their area and they were quite enthusiastic about the prospect of pooling our resources. Together with their technician we decided that it was probably a faulty motherboard so I returned it to my customer and gave him the bad news. It turns out it was his brother's computer so he's going to wait until his brother returns in September before he does anything. I managed to help him out a bit by telling him the webmail address of his ISP so he'll use that to check his email in the internet cafe down the road.

So that's two customers in two weeks from an initial letterbox drop of 1000 leaflets. If that trend continues I'll need to put out maybe another few thousand to reach my ideal level of 3-4 home troubleshooting jobs per week.

I'll distribute another 1000 leaflets next week and see what that brings in. It will also be interesting to find out if the original 1000 continue to bring in work. I can't let this distract me too much from Sydney though so I'll continue distributing the leaflets in small batches. When the troubleshooting work reaches a comfortable level I'll just stop the letterbox drops completely. From that point on I'll hopefully be able to rely on word of mouth alone to keep me in beer and movie money.

Monday, August 02, 2004

Hello friends, family and colleagues

What is this?

It's an online diary documenting my efforts at writing a software product that I want to bring to market in approximately 12 months time.

In internet speak it's known as a "blog" which is short for web-log.

Why are you putting all this stuff on the internet?

I talked about this in my first posting titled "Firstly what this isn't".

Trust me, there's method behind the madness.

So what is this project you're working on?

I gave a few small teasers about this in "So what software am I writing".

This is all a bit sudden. Are you sure you know what you're doing?

I've been preparing and working on this for about 6 months now. I haven't been able to make as much progress as I would have liked since I've been busy servicing my clients. From this point on though this project will be my primary focus.

Are you getting paid for this project?

No.

So what are you going to be doing for money?

Not a lot. Instead I'm going to be living cheaply so I can devote more time to my new venture. You can read about how I plan to cover my weekly living expenses in "Beer and movie money".

Since I wrote that I've progressed further with my plans for a part-time home computer support business. You can see the website for the new part-time business at http://www.TroubleWithYourComputer.com.au.

Are you still doing IT work for businesses or just private homes now?

A bit of both. I'll still be doing a bit of IT consulting for existing business clients but I won't be actively seeking new ones. That said though I'll gladly accept any referrals to businesses that may come my way.

Are you broke now? Can you still join us when we go out?

I'm not really broke as such, it's more like I'm pretending to be broke. I have savings but they won't last a full year so I do have to count every dollar I spend and put myself on a budget as though I were broke.

The good news is that I have budgeted for a limited amount of going out each week. There's not a lot of money set aside for it though so I may have to decline an invitation or two if I become especially popular in a given week. In such situations preference will of course be given to invitations from or involving attractive single females.

Are you going to start writing about me on your website

Probably not. I'm not going to write about my personal life at all here.

So unless you form part of the story of my product's development process I won't be writing about you. (sorry)

I want to read all your posts. Where do I start?

Really! You do?

OK firstly you're going to need quite a bit of time. There are 3 months worth of postings here and they fill more than 25 printed A4 pages. While they aren't all gold some of them must be at least mildly interesting as I have managed to attract a respectable sized regular readership from all around the world (Hello Estonia). If you were break up your reading into a few smaller blocks you should be able to get through most of the site without falling asleep.

The page you're probably looking at now is dedicated just to this post. The main page of the site lists only the most recent posts. There are monthly archive pages which have all the posts in a given month. On all pages the postings are listed in reverse order with the most recent at the top and the earliest at the bottom.

This reverse order can make things a little difficult to read so I've written an abridged version page with links to all the 40 odd individual postings. I suggest you start there and work your way through them if you're really interested.

If you make a habit of reading this site and other sites like it I suggest you use a blog reading system of some sort like Bloglines or FeedDemon which will track the sites you read and inform you when they've changed.

How does this all work? How did you make this site?

I use a site called Blogger to publish the site on the internet. It's actually quite easy as this tutorial explains.

People can comment on what I've written using the comment link at the bottom of each post. Their comments then appear at the bottom of the post for everyone to see.

To get the website address based on my name I went to Net Identity. They have lots of common surnames available there for a small yearly fee. You can get both a website and an email address based on your name.

This is all a bit geeky don't you think?

Yes it is a bit.