"A good head and a good heart are always a formidable combination."
- Nelson Mandela

Come Monday I'll be starting the envisioning phase of a 4 month project aimed to enhance the overall user experience in one of our flagship applications. I'm definitely excited about the project not only because there will be some really cool components to build but also because the project will be run using an Agile methodology. For the past several years I've been working on high dollar(long running), complex business apps that followed the Waterfall approach. Each of these projects adhered to the phases of your standard Software Development Life Cycle (SDLC) and at times seemed to drag on in the least exciting phases.

Agile development is definitely different than your traditional waterfall based project, not only from a structure point of view (phases and such) but also in it's principles, which are;

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Last week my work brought in a CF consultant from Universal Mind to help evaluate the performance of our flagship application and offer suggestions for improvement. On Tuesday this consultant was set up to give us a presentation on CFMX performance, and like most learning opportunities I attended the session. To my surprise, the consultant was Brandon Purcell... holy sh*t... I have been reading his blog for a few years now and regard him as being a CF rockstar along with the usual names.

Brandon was really cool and dropped some interesting tips on performance, some of which I had never considered before like using with an isolation level of read_uncommited to speed up SELECT statements. Of course this only applies to queries where the returned results don't have to 110% accurate as the drop in the isolation level will curtail around locks from INSERTs and UPDATEs. I never thought of using for anything other than managing 'atomic' transactions that included writing to the db.

Another interesting tip that he pointed out was the use of logging run time metrics directly to the screen but using HTML comments to hide them from the users. I think in non-MVC frameworks this would well and never really considered dumping runtimes to the display in a production environment, but I guess it's a quick way to see how well a page is rendering without going through hoops to get that info (in a large corp. environment where not everyone is privy to accessing production logs without waiting for someone else to get them for you).

Brandon had a ton of other great performance tuning tips, most of which I already knew about, but it was still cool to hear it from someone who has been around CF as long as he has. I really need to start going to more conferences and getting involved in some type of Users Group.

Now that the development and SIT phases of my current project are coming to an end, I've been focusing on preparation for Performance and Load testing. The application that I've been working on was written in Java and runs completely behind the scenes, so using Mercury Loadrunner or some other load testing tool for metrics gathering was out of the question.

The approach that I decided to take was to write a tool in CF that would parse the log files produced by the application (via log4j), aggregate the runtimes for various classes and method and then produce a graph to show average runtimes for various components. Most of the components that I will be measuring execute in an order of milliseconds so immediately I knew that I would have to tap into Java for working with time on that scale. The log files that I am working with output timestamps that look like this, 11/30/2007 13:01:59,123 (MM/dd/yyyy hh:mm:ss,zzz where z is milliseconds).

In the course of building my metrics tool, I wrote the following UDF to aid in calculating time differences in milliseconds. ** variables.runDate is set on instantiation of the object that this udf sits in.

A few months ago there was a collaborative effort from the developers at my work to get rid of our then current version control software, PCVS and excruciating Build Test Deploy strategy using Ant and AntHillPro. Although it took many months of convincing and proving out to senior leadership, we were successful in transforming our environment to use Subversion for version control, Maven2 and CruiseControl. The effort in establishing an enterprise ready environment for ourself was large but it was completed and is running smooth.

Although we still have PVCS and AnyHillPro for some existing (legacy) projects the goal is to have all new Java development done with the new tools. Being that, that is the case the new release of my project (Collision Prevention Program) has begun the development stagegate and one of the tasks assigned to me was to get our project ported over to the new environment. So for the past few days I have been slowly getting our project and developer workspaces up to speed so that in another few days the rest of the team can hit the ground running.

There are a few developers (2 to be exact) at my work that have a deep understanding of Maven so it has been critical that I learn as much as I can so that I can assist my team (and others) on questions if those resources are unavailable. As fate would have it, those resources for the most part have been unavailable during my journey to get us ported. I have had some definite headaches in getting everything set up, but in the end they have been resolved and my project and team are entirely set up for the months of development to come.

This experience (like many) has really enforced my confidence an aptitude in picking up new technology. I feel that I'm at a point with Maven and Subversion that I could handle most situations if they arise. I am by far no expert on each matter but I would consider that I have a strong working knowledge of our new environment. Hopefully in the weeks\months to come I will continue to learn and increase my understanding of the products and processes and if time permits I hope to blog about the experience.

The other day a buddy of mine who is still fresh in his career, emailed me about a possible side job that he had for building a small forum type application. In his email he asked me how much I would charge for the application, sending along a URL to a similar site. I started to write back with a long winded explanation but ended up cutting it short. I pretty much told him that the best thing he could do was to try and get a gauge of how much they were willing to spend based on several different 'decision points'. My answer was based on the mental notes that I had walked through when writing him back. Given the description of his client and the type of project they were looking for, I kind of figured that they were not looking to build a business off their idea but were more or less a group of guys that were looking to have some fun.

I thought it would be worth while to share some of the "questions" that I keep in mind when determining how I should bid out a project. Keep in mind that following isn't appropriate for all situations and/or might come as common sense for some.

What type of client are they, are they an an established company, are they large or small, what kind of seed capital to they have (if applicable)?
The idea really is to find out what type of financial state they are in. Typically if they are an establish co. or a startup with capital, they are willing to pay a premium (for a quality application of course). The simple economics of the matter would tell you that a company with more money, can afford to spend more for their business endeavours. The idea here is not to take advantage of their financial status but rather use it to get a gauge of how much to charge so that you don't under bid yourself. I have had several friends lose out on projects simply because their estimates were too low.

Is the client doing this for profit or for fun?
Chances are if the client is a business, then they aren't doing the project for fun. If they are, chances again would tell you that they are benefiting from it one way or another (pr, marketing\advertising, larger user community, ect...). In either cases, if the client is a business I would revert back to my first point in trying to get a gauge of a pay scale to use. On the other hand if the client isn't a business or forming a business, then I would step back and try to think about how I could offset my profitability in other ways than money. You never know, you could be building the next YouTube!

Is the project new development, or enhancements to an existing app?
New development in almost all cases means that your estimates won't be dissuaded by unexpected technical issues. While there is still the chance that something that you didn't account for (in technical terms) could go wrong, the fact that you are building from the ground up means that you won't have to deal with someone else's laziness, hacks or inexperience. I've worked on projects where the previous developers were unskilled and\or flat out lazy, causing me lots of unexpected fixing and figuring out of logic that just happened to work by coincidence. No body writes an application the same way that you do, so if you are asked to bid out enhancements to an existing app, make sure you get to see some of the source first before you give an estimate.

If it's new development, do you have a similar project (or can find a less expensive alternative) that can be tweaked to fit their needs?
Using an existing project and\or buying a lesser expensive alternative for tweaking, will in most cases provide the largest room for profit. For obvious reasons the simple fact that some or all of the 'code is already written for you', means that you can spend less time in completing the project. Again if you purchase something, you might run into the scenario that I described above about having unexpected technical issues. Writing an app from the ground up is usually more time consuming except if have (or have written) a really good set tools for code generation. Code generation lets your code work for you, people like Peter Bell are able to build hundreds of customized apps a year simply because he's built tools to automate much of the core code.

Would you be willing to do the work for less money than what you make now?
I mention this point because when it comes down to the end of the day, you should at least (imo) try and earn as much as you would as if you were working at your full time job. I try and calculate my hourly rate by taking my annual salary and dividing it by 2000 (40hours/week x 50 weeks/year). Using this as a basis, you can find out what the project would cost (at a minimum) to be worth your time. If you think you are overpaid or work for a client unlike the one for the side project, then you might have to be prepared to bill at a lesser rate.

Do you want the work?
The last point I usually consider is, how much do I really want the work. Like most people, if I don't want the work I might put in a high bid or just simply tell them that I'm not interested.  I try not to be insulting with my quoted dollar figure and/or with a decline of a project but ultimately you shouldn't do something you don't feel is worth your time. In the odd change that they willing to compensate you nicely for the work, then it might be worth considering.

Last week we had our first Design Patterns study group meeting, we have centered our learning around the book "Head First: Design Patterns" published by O'Reily. We chose this book over Design Patterns: Elements of Reusable Object-Oriented Software written by the Gang of Four (GoF) because we felt the Head First book did just as good of a job of explaining the patterns and object-oriented principles, but is a much easier and more interesting read. I highly recommended this book to anyone (or corporate group) that would like to begin learning Design Patterns or needs a refresher on Object oriented design.

The first meeting we had was on the Strategy Pattern, I volunteered to lead the discussion on the topic since I recently incorporated the design into the project I've been working on. I first started off with a discussion of Design Patterns in general, I think that we all understood the benefits of knowing and implementing these practices in our projects. My favorite, being the bridge of communication and intent that the patterns deliver. All members of the development team (project managers, architects, developers, ect..) who understand the pattern, also understand the problems that application faces and how the team intends to solve them. Making sure everyone in large development groups are on the same page is important.

I moved the discussion into the example given by the book, the SimUDuck app (Head First provides great motivation problems to solve). We stepped through the initial difficulties and requirements of the example, drawing out the class diagrams and talking about the downfalls of their early solutions. I then mocked up how the problem was solved using the Stragety Pattern and we talked about how it made most sense to implement that design. The discussion was then followed by a class diagram and overview of the implementation that I had used for my project. At times it felt like I was in another code review, but that was expected and encouraged. I was interested to see what the opinion of my fellow developers was in my implementation of the patter, I'm not an expert in OOD so the extra criticism and questions were meaningful. The session was closed up by me asking the group two questions, 1. how can you combat the over use of the strategy pattern, are there better ways to manage the 'strategies'? and 2, what are the different ways to delegate information from client and context to strategy and back if necessary.

Overall the session went great and I'm really looking forward to our next meeting which will be about the Observer Pattern. In anticipation, I have created a simple 'Subject' class for JavaScript to implement the pattern.

Every 3 weeks at my work, the Java Focus Group (a bunch of developers, me included ;) ) conduct one hour presentations followed by discussions on various topics related to the Java development procedures/tools/environments that we use. This is a relatively new process for all us (the company) as we have become much more focused on Java development.

Today our new chief architect spoke with us on various 'continuing ed' things that she has been a part of or initiated at companies she has worked for in the past. They have formed study groups to go over material in preparation for certification exams as well as held weekly presentations on design patterns. I think something like this could really benefit myself and the other developers at work. I think the idea of each of choosing 1 design pattern and presenting it to the rest of the group will really make sure that we have a some-what unilateral knowledge of different patterns or at least those that we don't already know.