The sessions were quite diverse and interesting on the first day of BarCamp. Since most sessions were only 30 minutes, it was difficult for the presenters to go in to much depth. However, 30 minutes is good enough to give a good introduction to a topic you might not know very well and give direction as to where more information can be obtained. Here is a brief description of the sessions I attended.
I am not sure that this was the exact title, but James Lancaster of Research Valley Innovation Center gave an excellent overview of his methodology for working with startup companies. The methodology, INNOVATEnRV, describes the stages of company startup and James explained the types of issues that startups would and should be concerned with at each stage. This presentation was the most polished of the day, at least of the sessions that I watched.
Drupal in 30 Minutes
Chip Rosenthal, from Unicom Systems Development, presented an overview of Drupal. For the uninitiated, Drupal is a content management system written in php. I felt is was a good introduction since I had never taken the time to look over Drupal. The one interesting nugget in this presentation was that Chip recommended looking at the Zen Drupal theme, that is not one of the stock themes in the installation, because it is very configurable and can give your site a look that is less like every other site running Drupal.
Social Media Marketing
Nikhil Nilakantan, from Social Span Media, gave a session on marketing on social networking sites. I have to admit that this is not a segment of the internet that I have paid much attention to. I am fascinated that these sites are as popular as they are with people over 22 years old. I understand LinkedIn, but I do not understand why I would want to really participate in the others. Nonetheless, Nikhil presented statistics on social networking site traffic that did make me take notice. He stated that the top 10 sites attracted 131.5 million unique visitors during December 2007 alone. The more interesting statistic was that the average visit on MySpace lasted 30 minutes (20 minutes for Facebook). Nikhil estimates that $1.8 billion were spent on social network related advertising last year. I have no doubt that someone will find out how to make advertising work properly with this type of market and usage pattern. The market is simply too juicy to pass up.
GWT and Gears
Anita DuBose presented the freshly launched AlphaBetaFinder.com from AppEngines. The site is a matching service for software and hardware vendors looking for alpha and beta testers for their products. The idea is that potential testers can register and provide information about what they are willing to test and what equipment they have available. Vendors can then search the database for matches and send invitations for testers. The site will inform the vendor when testers are interested and they can purchase the contact information for the testers. For now, everything on the site is free because AlphaBetaFinder is currently undergoing its own beta testing.
Tips on Podcasting
Jonny Dover presented some tips on Podcasting and Brad Dressler joined him to demo Audacity, an open source audio editing tool. I was quite interested in this session because podcasting is something I would like to try. Good tips were given such as eliminating pauses, working from a prompter or script (CuePrompter.com was recommended), and finding a way to include more than one voice on the podcast were given. I spoke with a few guys in the audience (sorry guys, I forgot to get your names) that mentioned GarageBand was great to replace using Audacity if you are using a Mac. They also pointed me to PumpAudio if you need low cost music to mix in to a podcast or the Creative Commons Audio section if you need low cost podcasting solutions.
Justin Bronn and Travis Pinney presented GeoDjango, which is the GIS branch of the Django project. Django is a rapid web application development framework for python, similar to what Ruby on Rails does for the Ruby developers. I felt is was a good presentation but really was limited in depth due to the 30 minute length.
I missed some of this presentation and I did not get the names of the guys presenting. The session introduced LINQ and the new C# 3.0 language features that make LINQ possible. They also gave a brief introduction to LINQ to SQL. This was one of the more interactive sessions that I attended. The audience was clearly interested.
Several of us adjourned to a local pizza place, which claimed to have the world’s greatest pizza. It was good but a claim like world’s greatest is difficult to verify. I sat across the table from Eric Fortenberry, Cayce Stone, and Jeff Jurica from OrgSync. These guys have a website product that is targeted mostly at universities to give their organizations (fraternities, student congress, etc.) a way to manage their membership and calendars and such. I did catch a portion of their demo earlier in the day and site was quite nice.
After dinner, I retired to my hotel room but activities continued late in to the night. A party went until 2am and folks continued to talk until around 4am. Scott Riggins, a good friend of mine from Social Mobility, filled me in. I wished I had kept going but a late night working for a client the night before kept me from pressing on.
Today I am at the BarCamp Texas conference in Bryan, Texas. In contrast to the standard tech conference that you have attended before, BarCamps are attendee driven. The attendees decide what sessions they want to present the day of the conference and nothing is decided in advance, other than the starting time and location. I did not know what to expect, but I have been pleasantly surprised. The day has gone like this so far:
- I showed up early so was recruited to help setup tables and chairs, which I didn’t mind. The entire conference is volunteer led and free to attendees so it felt good to at least put forth some effort to help out.
- Everyone registers as they get there. There is a wiki to add your contact information in advance but there is no obligation to sign up or pre-register beforehand. The registration was accomplished with a few Macbooks running spreadsheets and each attendee simply typed in their information.
- After the registration, a free t-shirt was given to each attendee, courtesy of the sponsors.
- Attendees then wrote the topics they wished to present on a whiteboard and signed up for time slots.
- The first few hours were simply meeting and greeting and ad-hoc conversations. Most of the attendees seemed to be working for either startups, companies that would work with startup companies, or freelance/independent consultants.
- Lunch wherever you can find it nearby.
- Sessions from 1pm – whenever people want to stop. So far, sessions are scheduled to about 6pm and the organizers made it clear than people are free to go all night if they wish. Sessions are going two at a time in one large room separated by a temporary barrier.
- Rooms are available for ad-hoc side discussions.
The sessions I have attended so far have been very good. They are not nearly as formal as a typical conference and there is much more audience participation. The one negative aspect of the sessions so far is that the room is divided by a temporary barrier and both speakers are standing on either side of that barrier so they occasionally will drown each other out.
I will post a summary of the sessions that I attended later in the day.
This is number 7 in my series of ridiculous happenings in my software development career.
I had been at Tiny Trader for less than a month when the CTO called a meeting to discuss a scheduled upgrade to the accounting system. The plan was that the MS SQLServer instance would be upgraded and the new version of the software would be rolled out to the users. The CTO asked me and one of my colleagues to watch over the consultants being brought in to perform the upgrade.
Everything seemed strait forward enough until the CTO explained that the upgrade would be taking place on a Tuesday evening. After explaining that it is never a good idea to perform a major system upgrade during the week, everyone assured me that I had nothing to worry about because these consultants were "highly qualified" and had estimated only a few hours for the upgrade.
Against my advice, everything proceeded as planned. On the evening of the upgrade, the consultants arrived and introduced themselves as Moe and Larry. Moe was older and clearly in charge. Larry was even younger than I was at the time and was obviously the technical person.
Moe and Larry were given the login credentials to the SQLServer machine and began the upgrade by sliding in the CD. Within 5 minutes, Moe and Larry were looking at each other in horror and discussing what to do. My colleague and I stepped up to the monitor and observed that the upgrade had failed in craptacular fashion, in mid stream, because a file was locked. After minimizing a few windows, I discovered that Moe and Larry had not shutdown the database service.
Just so we all are on the same page, let me give you a little background on the technology in use at this client. The server machine was a DEC Alpha running Windows NT 3.5 and SQLServer 4.2. The DEC Alpha part becomes important much later in the night. For those fortunate enough not to have lived through this stage in Windows history, Windows NT actually ran on processors that were not Intel compatible. They were not very popular but every now and then you would run into one. Windows NT 3.5 pretty much assumed that you knew what you were doing when you installed stuff. Installers back then also assumed you were smart enough to shutdown software before upgrading it so there was no rollback or anything like that when the install failed.
The rest of the night, or at least what those losers could stay awake for, Moe and Larry sat back while my colleague and I were at the keyboard, on the phone with Microsoft. Microsoft had good news for us. There were utilities that Microsoft had written to help with situations like this. The utilities were able to recover partially upgraded data files. The utilities only worked on data files that were generated on Intel compatible platforms.
We ended up having to hand edit some of the data files so that SQLServer would recognize them again.
Over 11 hours later, the SQLServer instance was back up and running, just in time for the accountants to come in to work on Wednesday morning. We even upgraded it.
Moe and Larry were long gone and never invited back for a return visit.
Tags: career craziness
Zed Shaw was a contributor to Rails and Mongrel.
I say "was" because Zed has decided that he wishes to distance himself from that development community.
Here is his post about it. It is quite long but entertaining.
Somehow "Burning a bridge" just doesn’t seem to capture the essence of Zed’s post.
Agile development methodologies have become the in vogue thing in software over the last few years. Hardly a month passes when an article concerning agile development does not appear in a major software development magazine or journal. An entire career path has even sprung up – the "Agile Coach".
There is little doubt in my mind that agile development is better than a more traditional, waterfall type methodology. When properly followed, agile development methodologies seem to keep programming teams more focused on the end goal. A large, up front design effort tends to grow out of control and lends itself to focus on unimportant details that could easily be put off until later. Estimating such efforts generally end with deadlines that are not as near to reality as management would like.
With all of the goodness to be had with the agile way, there are persistent myths that seem to surface. The most common myths I hear are:
- Agile development is faster
- Agile development removes the need for documentation
- Doing Test Driven Development (TDD) means doing agile development
Agile Development is Faster
The most common reason I am given for why an agile development methodology is chosen is because it will be faster than a waterfall methodology. I believe this idea manifests itself because of the agile development practice of iterative releases.
In my experience, agile development is not necessary faster than waterfall development. In fact, during the planning process, agile work plans often end up longer than waterfall work plans. Why is this? Because iterative development forces you to think in a more detailed fashion about the features being delivered, the testing time required for those features, and the integration time for these features after the development team is finished developing them.
Waterfall planning does not force this level of thought on the planner. I have rarely seen a project plan for a waterfall development project that didn’t have 2 big items at the bottom: Test and Release. Next to Test is a large number of hours (or days) and is generally pulled out of the air and "seems to be correct".
Testing, integrating, and releasing software is like paying tax to the IRS. Generally, tax is taken out of your paycheck (if you are an employee) and paid to the IRS at that time. Since it is taken a little at a time, you hardly notice it. Paying tax a little at a time is like testing and releasing often in agile development.
When I became self employed, I had to pay 4 times a year instead and I really noticed the large payments much more. If you pay at the end of the year in a lump sum, the amount would seem much larger. Not only that, but you have to make sure you have been saving enough over the year to make the large payment. Borrowing money to cover a shortfall can be expensive and draw out the payment process. This is similar to testing and releasing at the end during waterfall development. If you haven’t allocated enough time to test properly, you end up extending your testing time and probably missing your deadlines. The real problem is that you generally do not find this out until close to your deadline and users are not happy with the late news. "Borrowing" from quality by cutting testing short always ends up with disastrous results.
Agile development might not be faster, but it is more predictable and more reliable for planning purposes. Generally you end up with a much better product from a quality perspective.
Agile Development Removes the Need for Documentation
The second most common reason that I hear for using an agile methodology is that agile development removes the need for documentation. Most of the time, those who give this reasoning have only heard about agile development and not actually taken the time to read up on it.
There are agile methodologies that promote less documentation than is traditionally recommended. Closer examination of these methodologies will show that documentation is actually not necessarily removed, but instead moved around. Sometimes the documentation appears as note cards or post-it notes on a wall. Often times the documentation appears as an actual user, placed full-time on a project, who serves as the requirements specialist for the new system.
I am not very found of low documentation methodologies, with one exception. When the solution being developed is pure technical solution, I believe it is more acceptable. In other words, when the developers themselves will be the users of the end product I think it is acceptable to go with a lower documentation methodology like Extreme Programming (XP).
Even when a user is present on the team full-time, I believe that some documentation still must exist. There is too much opportunity for miscommunication between developers and the user when nothing is written down or diagrams are not drawn.
I often see projects that wish to pursue XP, or a similar methodology, but balk at the thought of dedicating a user full-time to the effort. Most of the time, they will dedicate the user for 25% and sometimes up to 50%. The allocation is generally less in reality than what is agreed upon because it is too easy to ignore something if you are not allocated full-time.
If a user is not present on the project team full-time, a portion of each iteration should be allocated to document the details of that iteration’s feature list to prevent unfilled expectations on both sides.
Doing TDD is the Same as Doing Agile Development
I could also replace TDD with several other agile development practices and the topic would hold true.
TDD can be pursued while using many development methodologies. I have seen it work well on waterfall projects as well as agile projects. TDD is a quality control mechanism to make sure components meet their expected functionality when completed and I recommend its usage on all projects.
TDD has become popular because of the promotion of its usage among agile development advocates, but the goodness can be shared by all.
In my opinion, the main practices that separate agile development from more traditional methods are iterative development and releases at the end of each iteration. If you are not following those practices, I do not believe you engaged in agile development. Iterative development forces development teams to constantly focus on features of the software and iterative releases focuses the team on quality. Those two practices are what drive the agile methodologies to deliver on their promises.
This is number 6 in my series of ridiculous happenings in my software development career.
I had left Upstart Consulting and gone out in to the world as an independent consultant. My first project was fairly uneventful but I had just started a new project for a small energy trading company that I will call Tiny Trader.
I came to work at Tiny because of a relationship I had with their CIO from my years at Upstart. She called me in almost a state of desperation and I could not say no. She hired both me and a close friend and co-worker of mine without even an interview.
On my first day, I was given a tour of the operations of Tiny Trader. During the 2 hour tour, I overheard announcements 3 times for all users to exit an application while the database was being repaired. A quick explanation confirmed my suspicions that the entire trading business of Tiny was run on MS Access and that several times a day the database was corrupted and had to be repaired.
As we entered the server room, I could not help but notice the huge pile of network cabling jumbled on the floor. From a patch panel above, wires led to the pile and from the pile back to the panel. As we looked around, a user entered the room and walked up to a server. The user rebooted the server and walked out. The administrator explained that all accounting system users were able to login to the database server with admin privileges and often rebooted the box when they were encountering unexplained problems.
A brief question and answer session revealed that no database dumps were occurring and even though backups were scheduled on the server daily, the data was obviously not backed up because of this. The administrator was oblivious to this important fact.
The good news was that there were no processes in place to hinder improvement. That bad news was the same as the good news.
On the second day of work at Tiny Trader, two users got into a fist fight in the conference room and broke the glass cover for the conference table. This was definitely going to be an interesting project.
I am back, after a pause for the flu and the Christmas whirlwind tour.
Jetbrains has released ReSharper 3.1. Although it does not contain the C# 3.0 functionality, it does contain some speed increases. Release notes can be found here.
If you have recently purchased 3.0, this is a free upgrade. If you haven’t purchased 3.0, purchasing this release will give you a free upgrade to 4.0 when it is released.
I highly recommend this add-in for Visual Studio.
This is number 5 in my series of ridiculous happenings in my software development career.
The project for the railroad company was now going full steam ahead but it was becoming quite clear that initial estimates were not close to reality. Interesting technology choices were made like writing the back end processes in COBOL even though the system was to be deployed on HP Unix boxes. Rational arguments as to why this was not a very good idea were frowned upon.
As moral continued to dip, management needed some way to motivate the troops for a final push to rescue the project from cancellation. A deadline of July 1 was selected as the date for code completion. To this day, I have no idea how this particular date was chosen. July 1 certainly had no basis in reality. Everyone on the project, even the management I am certain, had no faith in our ability to deliver in this time frame. Nonetheless, we were officially on a death march and I had little say in the matter.
Everyone was gathered in a large conference room for the big announcement of the new deadline and notification of vacation cancellations and mandatory 60 hour weeks. You know, the sort of motivational speech we all look forward to hearing.
As we entered the room, each person was given a small box. We were instructed not to open the box until the crucial moment in the presentation when we would be told to do so.
When the moment arrived, we all opened the boxes to find a new coffee mug. I was so moved by this mug that I have kept it to this day.
Management never figured out why the mugs seemed to have a negative impact to moral.