I’ve been exercising the last 4 weeks and today I had a bit of a ah-ha moment on my morning run. Starting a running routine is tough work, and I get frustrated often when I cannot make my goal and have to slow down. However, there are a few things I do that have helped me stick with it more this time than any other time I’ve attempted to run seriously. These few simple steps have been a great help and I’m on track with my goals. These steps also have parallels in Agile development, and I’d like to share my experience and insight with you, dear reader.

Commit with a Team

The first thing I did was to make a commitment with friends to exercise together and to sign up for Tough Mudder. The registration fee for this event is $150, so it’s an end goal that has both financial and health strings attached to it. Difficult exercise of any kind is very hard to do solo, but in a team – we have 3 regular people who are doing this now – it is much easier to stay motivated.

I associate this with the end goal of a software development project. Someone has invested some serious time and money commitments to see a project through, but it will often fail if attempted alone. It’s very easy to lose motivation on a difficult or long project when working solo. It is also easy to lose sight of that longer term goal and find it just too difficult to move forward. And, we all know that stress is bad for you, so it too has health implications (okay that’s a stretch, but go with it). Working with a small team of dedicated team members help keep everyone motivated and in the game. The team has a collective goal and when someone loses sight of the end goal, others are there for support and guidance.

Set a Goal, Form a Plan, Meet the Goal, Evaluate, Rinse and Repeat

As I mentioned above, I’ve committed myself to completing the Tough Mudder event. This is my goal, and it’s a very defined set of physical requirements that must be met. Now there is no way I could achieve what I need to without a plan. I could run, and I could workout, but I don’t know the best way to do those things, so I sought advice and found a great workout that is both challenging and meets my requirements. This makes me much more likely to stick with it – I have a time boxed goal and I know what I have to do to reach that goal.

In our exercise routine, we measure success by the week, and being in the 4th week of a 9 week initial program (the Navy Seal BUD/S Warning Order Workout) and on target is making me feel great. At the end of the week we realize and discuss our accomplishments, discuss what we could change, and then plan for the next week. For our exercise routine, this may mean changing the order in which we complete our daily workout, or it may mean adjusting meeting times or places to allow us to complete the next set of goals. In either case, this gives us short, measurable time periods in which to track our progress and readjust as necessary. This week we run a total of 9 miles (3 miles / 3 days a week), and we’re right on target! Rock on! 

In agile software projects, we do much the same thing. We commit ourselves to an end goal and typically the clients have a time boxed window for the project to fit into. In some other methodologies, a lot of up front planning is done to document the whole project, and it’s not until the end that success is truly measured. I find this difficult to deal with because going such long periods without reflecting on the current state of things seems like a bad idea. So in agile, we do sprints – my current project is doing 2 week sprints – in which we bite off a small chuck of the overall goal, commit to it, and at the end we look back and measure our successes and failures. This brings failures and areas to improve upon to the surface much quicker and ultimately keeps the team on track for the end goal. It also feels good to meet these goals (in exercise and software development), and it keeps the motivation high.

High Five Those Who Are In It With You

I have a habit now of reaching my hand out to high five other runners (strangers) I see on our path! Some respond and smile, some ignore me, but I will continue to do this. I also make it a point to high five those who exercise with me – at the end of a hard workout, and at the end of a week. A salute to their hard work, and a confirmation of my hard work.

I feel it’s a recognition of their dedication and effort, and it’s a motivation for me to keep up the hard work – if they can do it, so can I! I don’t mind those who don’t respond in this context – maybe they are very focused, or just afraid to touch a sweaty overweight guy. But I really enjoy those who do respond. It gives me a burst of energy to know that I can help someone else feel good about their accomplishments (and running at 6 am in Texas is an accomplishment at any distance!), and I hope it does the same for them. I also get energy from the fact that they are encouraging me as well.

I see this as the same thing as the task board, daily standups, and retrospectives in an agile project. It feels really good to move a task from backlog to in progress to completed. It feels really good to tell everyone about the accomplishment during the standup and receive typically very positive feedback. And at the end of the sprint, these things are recognized again in the retrospective. It all goes towards the idea that small accomplishments can be recognized and motivate the team to keep going. Even if I’m really tired from a hard workout, getting positive feedback in my daily standup gives me the strength to give it my all for that days work. And during the retrospective, we make it a point to highlight the positive efforts of the team and address the negatives.

Fin

So, those are my thoughts on exercise and agile! Now if only I could apply this to nutrition and agile, I’d really be rocking! Anyway, the next time someone does something that deserves a positive acknowledgement – in any part of your day – give them a smile and a high five! It may seem pretty goofy to high five (that’s old school cool right?) – my wife is constantly embarrassed when I do it with her – but I guarantee the person receiving and you will walk off with a hint of a smile on your face!

I don’t have anything really planned for this post so I’m just gong to brain dump for a while. I could start with some interesting weather updates – it’s been raining. This is really good for our area and I think I’ll get out tomorrow (weather allowing) and burn some stuff I’ve had in the back for a while.

I also attended RefreshBCS last night and had a great time getting together with local entrepreneurs as well as some speakers from Austin. The speakers were from a company called TechRanchAustin, which totes itself as a business accelerator. They made the distinction between acceleration and incubation, which I found interesting. I also got a boatload of book recommendations – the best of which I think will be The E-Myth Revisited. Several people in the crowd had read it, and re-read it, and re-re-read it, and found insight each time. It must be good if it’s got that kind of capacity to affect business over a long term.

I’ve also been rushing to get some of my consulting projects wrapped up before the baby is born. My wife is having more and more contractions each day and having a harder time getting around and taking care of things. You too can try this at home – take a full sized watermelon (~ 6 lbs), tape it to your stomach, and walk around for an hour. I guarantee you’re going to be thankful it’s not you caring that around 24/7! I know I don’t help her as much as I could with the house and whatnot, but I’m trying to get our credit cards and other debts paid off before we take on the new baby.

Back to the consulting – I’ve been learning more new systems than I can throw a stick at. Joomla, WordPress Templating, Drupal, Zend Framework, NCover, and a few more I’m forgetting I’m sure. Even with learning all these in and out I’ve been feeling like I’m neglecting other technologies and skillsets I cherish. I’ve been looking for a good way to keep my security skills up to date, but it is very difficult to stay on top of that.

I know and will always have a great foundation to build on here but the security industry as it is relies heavily on 0-day exploit knowledge. If you don’t know the exploits exist, how can you possibly protect against them? And if you concentrate on building security systems in depth for you products, how much does it end up costing you neglecting the product itself? This is something I’m struggling with currently and it’s getting the best of me at the moment. I have been balancing the projects I’m getting paid to do with the realization that I’m neglecting my business administration and my network administration. I’ts a terrible feeling. Anyone volunteer to help with this?

My motorcycle is still in the shop and they have ordered some new clutch plates for it. I’m wondering why the hell it’s taking so long – a bike shouldn’t be anywhere near complicated as a car. Especially the older ones that rely on good old nuts and bolts rather than computers and cooling systems. I’m hoping to get it back soon so I can grab a motorcycle permit up on campus and save a boatload on gas each month (again, weather permitting). The motorcycle permit costs $35/yr (with a primary vehicle permit already) and it would cost me about $5 every two weeks to fill it up. That’s in contrast to the old 2004 v6 Ford Ranger I’m driving around now which takes (at minimum) $20/week.

And finally, it’s with a sad heart that I have to say I shaved my beard. I had a good 2 weeks going on it and it was filling out nicely, but my wife really hated it. It was too short to get soft enough for her sensitive skin. We’ve made a compromise. When the baby is born, I can grow it out. I plan on documenting the process on my Picasa Web account.

Well, that’s it. By the way, all of this brain dumping idea was due to the book Pragmatic Thinking and Learning: Refactor Your Wetware. Go get your copy (I have to return this one to the AgileBCS library and get my own)!

Sometimes I want to take a tool from one project that is under subversion and use it in another. The problem is with the existing .svn directories. Because the files are already in one repository, copying directly from there to another project will cause conflicts in the other repository.

There are quick and easy ways to solve this in both Windows and Linux. To get around this in Windows copy the directory to a temporary folder and use Windows find to search the directory for “.svn” and delete all the directories it finds. From there just move the folder to the new project and add it to source control.

On Linux it is even easier. Copy the folder to a temporar location and run “find . -type d -name .svn -exec rm -rf {}\;” . This will delete all .svn directories. Then move the tool directory to your new project and add it to source control.

I recently helped a friend out with the technical side of going “agile”. This meant setting up some project source control and automation for build and test. I have a pretty advanced automation setup on most of my projects right now. It’s far from perfect (I don’t have nightly releases being tagged, etc), but it gets the job done. But I sometimes forget how long it’s taken me to learn the lessons and get things set up correctly (AFAIK – I’m no expert). I may be missing a lot but I always try to improve what I’m doing and review it often for lessons learned.

As I said previously I had about 2 hours with my friend to set up an automated build, and teach him the virtues of Test Driven Development and Continuous Integration. We set up a project with a simple NAnt build file that had the basic targets – init, clean, compile, test, and build – and then got into some code with a 3 tier project (presentation, BLL, DAL) and a test project. This all went well and he caught on quickly which was nice. I sometimes have a hard time teaching things because the ideas are so ingrained into me that they are difficult to explain to others.

I raised a red flag with him because he was trying to introduce a lot of new technology at once. I asked him to really think about which technologies he wanted to implement and get started with. The obvious ones to start with are automated build (Ant/NAnt), unit testing (PHPUnit/NUnit), and Continuous Integration (phpUnderControl/CruiseControl.NET). Beyond this I asked him to wait until he was comfortable with these before adding things like an ORM he was unfamiliar with.

One of the worst things to do is jump into a new project with 100% new technologies that first have to be learned. We always want to play with the latest and greatest and there’s a good reason for many of them to exist. But taking on too much at once and not coming away with a good understanding of any of the technologies can also be harmful. Pick your new technologies for the value they will bring, not for the coolness factor.

The other side of this coin is that with a good automated build, testing, and continuous integration, later down the line it is much easier to introduce these new technologies that may have real benefits. Your code will be much more flexible, and your team will be much more comfortable switching out older technologies for new ones because the tests will tell the truth. And with a good source control setup, you can always branch new technology development and merge it later if the team deems it worthy enough to add into the mainline development.

I would like to write up a series of posts covering the very basics of the technical side of agile, with this post being the first. Agile development encompasses everything from technical issues to management to customer interaction. It can be difficult to jump into without knowing the how or the why of each part. There are also several different ways to implement agile development. But it is often easy to start with simple and sound technical practices. A grass roots technical movement can have a great effect on changing a teams culture. And, it’s usually easier to ask for forgiveness than permission, and definitely easier to ask for it when your project is wildly successful because of some small steps taken in the right direction.

Another good way to get involved with agile development is to find a local user group or a development shop that may be willing to have regular meetings with you to show you the ropes and review what you’re doing. My office has been good about allowing me to do this through community training and user group interaction. Part of the reason for this is that my projects are on sound foundations and they value the fact that I don’t waste time developing terrible code…

A friend of mine recently mentioned the idea of doing a code dojo – getting together with other professional programmers and writing code to throw away. The code is not written to address any specific problem, but to teach everyone good programming practices. It’s great to know theory in computer science, but to practice it is to embody and internalize it. The CodeKata blog has several good posts about the idea. I’d be interested to hear from others about doing this – what outcomes did you have, or what would you like to see them address if we started one?

The guys at LifeHacker just put up a post about starting conversations with strangers. Now, I’m a pretty introverted guy – which actually helps me as a programmer look inside to find solutions to problems. But recently since I started consulting again I’ve had to find my extroverted side and start up those difficult conversations. I’ve found things like JellyBCS (Facebook, Twitter, and old fashion web) and user groups (.NET, PHP, and AgileBCS) have helped with this.

My challenge for you is to start up conversations with at least 3 random people a week!

I have the luxury of working in an office that does not do cost recovery. We do, however, still have to give our clients time estimates from time to time. It helps us plan out our release cycles and give our customers some expectations. More often than not though, our “estimations” come from clients who say they need a project done by x/x/xx because of factors a, b, and c.

I have seen a lot of talk within the AgileBCS group about project estimation, and usually it ends with “yea…it’s a tough problem.” Indeed, it is, and usually every project seems to be unique in some way or another with regards to estimation.

Anyway, I ran across a reposted TechRepublic article today titled Estimate a project’s bottom line using top-down techniques. The interesting thing about this article is that it was originally posted in June of 2001. A lot of the techniques are still in use and come with different names now, usually correlated to a specific methodology it promotes.

An interesting read and an interesting discovery that in business terms, tech projects really have not gone a really long way to becoming more accurate.

I will be giving a presentation on PHP Unit testing on Thursday for the BCS PHP Users Group. I’m fairly new to the new PHP world (object oriented, well designed PHP apps), but my pursuit of pragmatic programming skills has led me to bring a lot of my .NET experience to the table as well. I’m going to be covering a broad range of topics and hopefully bring the audience into the mix as well.

My topics include PHP Unit testing with PHPUnit, project automation with Ant, and automated documentation generation using PhpDocumentor. I’m also going to introduce Php CodeSniffer for styling.

These topics, while being shown in a PHP environment, carry easily to other languages. In fact, projects such as Django incorportated a lot of the ideas I’m going to present directly into their programming environment. They even go a bit further and automate database synchronization and access.

My point for this blog post is this: good programming practices are not rooted in a specific language or methodology. They transcend language and become instilled as best practices for any project. And, I hope to see you there for the PHP presentation, because I’m really hoping to raise the bar for programmers in the area.

Well I haven’t blogged lately and I thought I would throw something out there about my current efforts. I’ve been at work doing a lot of PHP stuff lately and I’ve been really unsatisfied with the setup I had. The code I”m working with is mostly legacy PHP 4 code, so I’m rewriting it using PHP 5 OOP techniques. This includes a TDD approach using PHPUnit, a well though out project layout, and a simple shell script to run the test runner.

However, I have been looking for an even better solution. I’ve been experimenting a little on my own time with things such as Phing, Xinc, phpUnderControl, and CruiseControl. I’ve found a lot of good resources at Planet PHPUnit.

As I find a good solution to move code between development, staging, and production while designing with orthogonality in mind, I will post them here. Within 6 months I hope to have a seamless, repeatable process for developing PHP projects using truly agile methods.

Today was the first meeting of the AgileBCS group. About 12 people showed up, and I knew most of them from previous community events. I have noticed that people with a passion for development are typically the first and only ones to come to meetings like this. They are looking to share their successes in software development and learn from others who have had success as well.

It was a good meeting and I met a few people I can learn from and reminisced about working with a few of the others. I’m really interested in working with a few of the guys who have done Continuous Integration and automated deployment of PHP applications. I have a nice system – svn, NAnt, NUnit, CruiseControl.NET – that I use for .NET development, but the PHP world is now foreign to me and I’m really putting it to the test with the demands of an enterprise level development platform.

The meeting was very informal and I was rather disappointed that no one took charge and really opened up a topic to the whole group. As such, about 4 different groups split off conversations on everything from homebrewing beer to introducing customers to agile practices. I’m hoping that next meeting will have a focused purpose and will bring more value to the stated mission of the group.

We also decided to review The Pragmatic Programmer at the next meeting. I’m pretty excited about this, and my copy came in the mail today. After reading the preface and foreword, I am hooked. This looks like just the key to increasing my ability by learning successful habits and practices from other people’s experience. When all is said and done I hope to integrate the new knowledge into my every day learning and development as well.

So, I have hope that this group will become strong and will not die off like so many others I’ve recently been involved with. Development groups in this area are typically small and scattered and if they survive more than 2 or 3 meetings I would consider them a success. Here’s looking forward to another AgileBCS meeting!