In software development, it is no great secret that things don’t always go according to plan. It’s a stressful job, to say the least, especially when things go wrong. I would not be at all surprised to learn that there exists a positive correlation between software development and rates of trichotillomania.

So what puts a project at risk, and how do we plan to deal with these risks when they occur?
Steve McConnell, the patron saint of practical software development practices, eloquently identifies some of the common problems that bring software projects to ruin.

TYPES OF RISKS

CAN-DO ATTITUDES

As McConnell points out, in software development, optimism can be deadly. An optimistic, can-do attitude often leads to the creation of impossible schedules that puts projects at risk of failure. In order to mitigate this risk, it’s imperative that developers and managers alike adopt a healthy, pessimistic attitude. Plan for the worst and aim for the best. Don’t ever rely on luck or good fortunes to see your team through to the end. Optimism and hope is not a replacement for solid planning and risk management.

FUZZY REQUIREMENTS

Software development companies often bow to the pressures of their clients and rush through the requirements analysis and design phases. This is always a mistake. Many studies show that the cost of repairing requirements mistakes outweighs the cost of repairing implementation mistakes by several orders of magnitude. Spend the time to get requirements right before starting even the design phase of the software. In the long run, it will save your company a bundle. And don’t take just my (or McConnell’s) word for it – there is plenty of plenty peer-reviewed research demonstrating the validity of these claims.

GOLD-PLATING

Gold plating occurs when developers and managers add features to software to make it “better.” This often occurs past the requirements and design phase, where the implementation of a new feature is far more costly than it would have been had it been planned out in the initial phases of the software’s development. Customers, developers, and managers alike are all responsible for this. Each stakeholder should take different steps to manage this risk:

• Developers: it is the developer’s job to explain to managers what is possible and what isn’t. As most developers know, what seems like a simple change on the surface (adding a button that performs some nifty function) sometimes requires substantial modifications to a whole subsystem. Accurately estimate the difficulty of any proposed change and make sure that your managers are fully aware of what functionality may be placed at risk by the change.
• Managers: it is your job to determine how important a change is to the software’s “mission” since they are the ones most in touch with the customer’s point of view. If the change is a convenience change, leave it out. It’s often tempting to add nifty little features toward the end of a project, but the road to hell is paved with good intentions. On the other hand, if the change is absolutely vital to the mission’s success, explain this to the developers so that they don’t take a morale hit from going back and rewriting old code.
• Customers: customers are an integral part of the development team and the whole reason behind the team’s existence. It is imperative for project success that the developers know precisely what requirements they need to fulfill. Customers should review requirements documents carefully before signing off on them and not hesitate to point out any mistakes. Remember that misunderstood requirements cost tens to hundreds of times more than implementation mistakes.

THE MYTHICAL MAN-MONTH

Project managers sometimes fall into the trap of viewing software development as an assembly line process. It leads to the idea that if a project is behind schedule, adding more developers to the team will automatically bring the company closer to the goal.

This sort of thinking is horribly and fundamentally wrong.

McConnell cites a number of studies demonstrating that not only does adding developers at mid-to-late phase during a project not increase productivity, it actually detracts from it. The reason for this is simple: in any complex project, it takes time to bring a new developer up to speed on both the domain knowledge and the project architecture. Existing developers on the team must then spend some of their time fixing the inevitable mistakes made by the new team member and attempting to train the new developer.

So how do we manage this? The answer is fairly simple. Build your team immediately and then involve them at every phase of the project. A developer who was involved in the requirements analysis and the design phase will be more productive than a developer who is starting out with little to no knowledge of the project’s intricacies. Involvement is the key.

SILVER-BULLET SYNDROME

This risk tends to apply more to developers than to project managers. We’re a technology-loving bunch, on the whole, and so when a new framework comes out that promises to make our lives easier, we’re almost instantly ready to jump onto the bandwagon. So optimistic are we that we’ll gain productivity from the new technology that we revise our software cost estimates to reflect the expected productivity gains.

This is dangerous.

Although new technology often does increase productivity, it is not possible to predict the sorts of things that can go wrong with a new technology. It is also important to factor in time for training on the new technology, a facet of a developer’s job which is often underestimated.

While nothing is intrinsically wrong with trying new technology, it is important to be conservative with cost estimates when walking on uncertain ground. This ties in to the risk of optimistic thinking, outlined above.

RISK MANAGEMENT

There are many other common types of risk that fall well beyond the scope of a blog post. The important thing for developers and managers to do is to sit down with one another and draft a risk management plan. The trite aphorism is telling: if you fail to plan, plan to fail. Determine at the beginning of a project what might go wrong and how best to deal with the situation should it occur.

Following this strategy will result in better software for customers, lower costs of development, and fewer grumpy developers.

Over the past few months, I have been working on improving a computer tech site’s search functionality. The site was built with Wordpress, one of the more popular Web Blogging solutions that apparently can act as a CMS if needed. The site was great in all ways but searching. Out of the box, the Wordpress search functionality searches for what appears to be the basic presence of a word in a blog post or title, then orders the results by post date. This approach has a number of flaws, especially for sites heavy with computer technology lingo. The first of these problems is abbreviations.

Abbreviations

As many of us know, we computer geeks love abbreviations. Whether it be the various components of a computer (RAM, CPU, PSU ) to the documents that we write/read (SRD, SOW, DDD), and then there are the various software technologies we use (RIA, AJAX, CSS). Because the default Wordpress search only performs a simple search for the presence of the search terms, abbreviations can return all sorts of crazy but logical results. Take for example, the search term “RIA.” Using the default Wordpress plugin, it returned various articles about indust-ria-l devices.

Relevance

The other major issue was that, thanks to Google, users have become spoiled with this whole concept of relevance. People expect the top results to be the pages that are most likely related to the topic they’ve searched for. Determining relevance varies from search engine to search engine, but mostly it is determined by the number of times a search term is used, where it’s used, and the words surrounding it. Making a site more relevant for certain keywords is such a big deal that it has spawned a brand new abbreviation: SEO. Having a relevant search capability for your own site tends to be a big deal since it makes life easier for your readers/clients.

To resolve these search issues, I ended up trying numerous plugins. This approach led me to the following conclusion: plugins fall into one of two categories. There are the “search everything from author to page/blog title” plugins and then there are the “search by relevance, but only for blogs or pages and maybe, if we feel like it, their titles” plugins. After I started paying attention to the timestamps on the various plugin pages, I reached yet another conclusion: these plugins are extremely short lived. Most of them receive up to a year’s worth of development, and then the developer’s disappear off the face of the Earth.

Ultimately, Google came to the rescue with Google Site Search, a special embeddable code snippet that allows you to use Google to search only your website. Unfortunately, this bears some consequences of its own. Unless you like various text ads all over your results, you have to subscribe to the service with fees based on the page count of your site. It’s a bit steep at $100-$250 per year for smaller sites and a lot more for bigger sites. Also, the results are a little painful to customize without doing some good ‘ol XML API interfacing.

In conclusion, Wordpress searching sucks. The Google site search makes it sort of better, but I really wish Wordpress would devote some of their resources to improving their default search system. The pain I suffered trying to improve it via plugins and Google has certainly made me reluctant to use Wordpress again.

CSS3 promises to include some very cool features that will make styling much easier for advanced layouts. Unfortunately, there is only some browser support for some of these features at the time of this post. I’ve seen some support for these in Firefox, so you can at least begin to play around with some of the features. However, I would hold off on using these exclusively for your layouts until there is more cross browser support.

Below are some of the features that I’m looking forward to using.

1. The border-radius property – Allows you to create rounded corners for box items. What a time saver this will be! No need for images or fancy techniques to get the rounded corners you want. Supports the capability to specify a radius for one or more corners. Currently supported in Firefox and Safari 3.
2. Multiple Backgrounds for a single element – Ever wanted to apply more than one background to a single element? Well now you can! For the background property, simply separate backgrounds by commas. At the time of this post, only supported by Konquerer and Webkit.
3. The box-shadow property – One of the features I’m most looking forward to. Allows you to apply a shadow for box items even with rounded corners. Again no images required! Currently supported in Firefox 3.1 and Sarfari 3+.
4. The border-image property – Allows you to specify an image for a border instead of a normal border and can be applied for one more sides. Currently supported in Safari and Firefox.

It has recently come to my attention that a surprisingly high number of people believe that computer programmers have little or no sense of humor. This has led me to compile a few jokes to finally get rid of this misconception. Hopefully, upon reading this blog it will make people realize that we programmers do have a sense of humor… It just happens to be a very different kind. After all, there are only 10 kinds of people in this world: those who know binary and those who don’t. Enjoy!!

Q: How many programmers does it take to change a light bulb?
A: None – It’s a hardware problem

“Knock, knock.”
“Who’s there?”
very long pause….
“Java.”

Q. Why do programmers always get Christmas and Halloween mixed up?
A. Because DEC 25 = OCT 31

Q. How do you keep a programmer in the shower all day?
A. Give him a bottle of shampoo which says “lather, rinse, repeat.”

Q. “Have you heard about the object-oriennted way to become wealthy?”
- “No…”
- “Inheritance.”

Two bytes meet. The first byte asks, “Are you ill?”
The second byte replies, “No, just feeling a bit off.”

Eight bytes walk into a bar. The bartender asks, “Can I get you anything?”
“Yeah,” reply the bytes. “Make us a double.”

Programming is like sex:
One mistake and you have to support it for the rest of your life.

The English language has a great capacity for ambiguity. Among words with similar meanings, working in the computer industry brings to mind the words “geek,” “nerd,” and “dork.” Most people would not differentiate between the three, but what I can tell after four years of studying computer science at UTA is that “geeks” and “nerds” are slightly different and tend to have a positive connotation whereas a “dork” tends to have a negative connotation.

From my exploits in the computer world, I have found that a “geek” tends to have an interest in subjects of academic or technical importance. A “nerd’s” interest seems to be more trivial, like knowing every line in every “Star Wars” movie. That being said, I believe a geek tends to have a higher intellect than a nerd and more specialized skills. I might go as far to say that a nerd is a geek, but without skills.

Geeks usually choose their concentration over conformity while a nerd chooses his obsession over conformity. A dork is described in the dictionary as someone that is stupid or ridiculous. In high school, if someone called you a dork, you need to check yourself and possibly buy some deodorant. However, if they call you a geek or a nerd, more than likely one day they will be working for you. The truth of the matter is that I consider myself all three and I am proud of it!

Last week I was working with a Java library for manipulating SVG’s. With the library came a Javadoc, but when I looked through the Javadoc, I was surprised to find that none of the methods had any explanations. Classes were shown as well as the methods that belonged to each class. But what did doScale() do? What was the purpose of SVGAbstractTranscoder? None of this made sense, and while a “getting started” guide was provided, it wasn’t thorough and only explained a few simple tasks, none of which helped me do what I was trying to. Long story short, I had to move to a more well-documented library, and though it has less features, I at least could figure out how to use these features as the documentation was vastly superior.

Comments are immensely beneficial to anyone that is going to be dealing with your code, including yourself. There are many places where comments are helpful, including those describing a method, those describing class properties, those describing classes, and those describing the purpose of a block of code. Of those listed, I feel commenting a method is the most beneficial. Object-oriented programming (OOP) naturally tends to have many method calls across many different classes, and being able to find your way around and determine the expected input and output of a method, but also the purpose of a method can be a lifesaver. Even one brief sentence can help someone out that would otherwise have absolutely no clue what this method you wrote is for. Not only do comments help you later on down the road, after you’ve written the code and possibly forgot what a method was for, but it has the immediate benefit of making you think, “what is the purpose of this method?” If you comment methods before you write the implementation, you have a “definition” of the method, and when implementing your method, you’ll be able to tell if the purpose of the method is becoming fuzzy or if the code you’re writing is spot on with your original intentions of writing the method.

It is also important to note that most modern IDE’s have the ability to parse through comment blocks above methods and the better the comments, the better smarter the code completion will be. For the purists, some IDE’s allow you to throw errors at compile-time if a method is not commented, a feature that I sometimes find a burden, but more often than not has led to me writing better code than I would have otherwise.

Some feel that well written code doesn’t need comments, and some (I don’t get this logic) feel lots of comments are bad because it demonstrates that the code is not self-descriptive. This is just plain wrong, well-documented code rarely, if ever, means code is sub-par. In fact, I would go as far as to say the opposite is true, if I see good comments, I get that piece of mind that the author of the code knew his intentions well and planned out the code well enough to be able to define a purpose for each method, each class is carefully targeted and named for a specific purpose. If I saw a library with 500,000 lines of code, I would honestly be pretty scared of the stability and robustness of such a library.

Lastly, if you don’t want to take my word for it, look at any open source code library. I’d be willing to bet comments are poured liberally throughout the entire library. It’s not uncommon for the comment of a method to be longer than the implementation of the method. There is such thing as too many comments, but too much is better than not enough.

So, in conclusion, don’t be afraid to use comments, they’re your friend.

While WordPress is a very powerful publishing platform all on its own, if you combine it with just a few of the thousands of available plugins out there today, and WordPress becomes even more powerful. Here is a list of essential WordPress plugins that are easy to use and cut down on development time. Check out the rest of our site to see all of these plugins in use.

1. Breadcrumb NavXT – Allows you to easily add breadcrumbs to improve your site’s usability. Includes an admin interface so you can easily customize the look and feel of the breadcrumbs.
2. cforms – This plugin allows you to easily create form templates for use throughout your website. Features include form backup & restore, AJAX support, a database tracking interface so you can manage contacts and much more.
3. ColorCoder - This plugin allows you to insert code snippets to your posts with easy-to-read syntax using highlighting powered by GeSHi library.
4. PS Auto Sitemap – This plugin automatically creates a sitemap for your site. It is easy to install and configure. Supports exclusion of single pages and comes with CSS skins you can select from. In addition, you can use CSS to further customize the look & feel.

Browser statistics for August 2009 are in and indicate that Internet Explorer’s market share is diminishing slowly. According to w3schools web statistics, Internet Explorer’s combined market share for IE 6, 7 and 8 dropped a modest 0.1% in August. Firefox dropped in August to 47.4%, but still holds the largest share. Chrome gained market share to 7.0% while Safari stayed the same at 3.3%.

The statistics do show some good news for web developers as Internet Explorer 6 market share drops from 14.4% to 13.6%. This is very good news indeed! I don’t know about you but the demise of IE6 cannot come any sooner.

While we wait for that glorious day, you can sign the petition to kill IE6. You can also get a laugh at the “Save IE6” site. You’ll know what I mean when you visit.

In January 2008, I spoke with Rona Shuchat, Program Director of Application Outsourcing (AO) Services at IDC, a major technology market research firm, about business trends in the IT industry, specifically in application development services. Near the top of my list was the subject of consolidation. What I meant by consolidation is what has been recently happening with HP EDS and now Dell Perot. Here are some of my opinions on this “fashion trend.”

1. Dell Copies IBM – Why did Dell buy Perot?

There is virtually nowhere for Dell to go in their current business. Dell’s direct-to-consumer business model is no longer unique and overseas competition has overcome their manufacturing cost advantage. To grow, Dell thinks they have to copy HP, who copied IBM, and build out an application services business. However, the low-cost culture at Dell is dramatically different than the quality culture at IBM. This will make it very difficult for Dell to digest Perot Systems and properly manage it. So what should Dell do…see number 2!

2. Fire Dell – Put Perot Systems in Charge

With all the difficulties that Dell has had with their services business, I say Dell should move their executives out of the way and put Perot Systems in charge of all of their services business – now and with future acquisitions. Perot has a proven experience in this market and is positioned to benefit from future government spending and all the dollars that will be spent on universal healthcare.

3. Lemming Syndrome

The trend right now is for every major enterprise vendor to have 3 parts to their business – application services, software products, and hardware. Firms that are missing one or more of these areas will look for acquisitions to fill in the blanks. There is a lot of pressure to do mergers – from big firms looking to corner the IT market and shareholders looking for an exit strategy. But does following the herd make sense? In the short run, merging will allow firms to cut costs, i.e. fire “redundant” employees, while raising prices as competing firms go away. But after the short-term gains, what happens next? Will these firms fall under their own weight…see number 4!

4. Spin-Offs

What happens when every Tier 1 company has been put together the same way? Ultimately, the giant Tier 1 firms will experience the clash of cultures – product people are fundamentally different than services people. At some companies, services will triumph and support for products (hardware & software) will be dropped. For other firms, they will spin-off the organizations they spent billions to acquire.

5. Here Comes the Small Fry

Customer frustration at dealing with a limited number of large firms will lead to renewed opportunities for smaller, more focused suppliers. Eventually, the market fad will switch from “diversify” to once again focus on your “core business.” Buyers will now be under the gun to build relationships with boutique firms. Instead of pursuing large projects with large firms, companies will break initiatives into smaller projects and begin to experiment with alternative technologies.

All of this leaves me wondering, … will Dell Perot or any of these multi-billion dollar conglomerates pick up the phone for less than $1 million? and how will they provide the white glove service that comes with application development services?

Normally in this humble blog space you will find interesting topics like tips on how to make your web applications awesome, what new technologies are out there for you to use, or how to write proper SQL procedures. But today we shall be taking a little detour to talk about one of the greatest upcoming disasters of all time. No, not Windows 7. No, not Duke Nukem Forever (Rest In Peace). No, not even 12/12/12 from the Mayan Calendar. Nay, we shall be speaking about our true impending doom – The Dallas Cowboys and the Texas Rangers having a game on the same day.

For those not in the know, and wanting to be in said know, our Ayoka office is located in the growing city of Arlington, Texas. Yes, the rumors are true – the people who designed this city are the fruit of many loons. It’s because of these warped minds that we have such great things to call ourselves. The biggest city without mass transportation, the town where principals come to retire (there are over 60 schools including 6 high schools), the suburb of infinite strip malls, the only place on Earth where you can go into a book store for some educational books and then walk next door and see strippers – take your pick. Having lived in this city my entire life, I’ve come to have an understanding with the quirky flaws of our fine city. Seriously, who needs to be going over 20 mph trying to merge onto Highway 360 South from Division Street? Not somebody from Arlington!

But what takes the cake is this new Cowboy’s Stadium, also affectionately known as the Big White Beetle (BWB). This beast stands about 300ft in height and can be seen from nearly anywhere in the DFW Metroplex. Now it’s not that I’m mad that the Cowboys will be coming here to play in Arlington, because we need something to hire all the people from the local GM plant. The price tag is also not a focus of blame, and the fact that the city’s smokers are killing themselves to finance the world’s largest television screens is beautiful irony. What really colors my britches is where they put that colossus of metal. Yep, you guessed it. Right next to the Rangers’ stadium!

I had assumed that the people making these decisions were literate, but apparently they don’t know how to read a calendar (and luckily this blog post). For non-sports fans, the baseball season and football seasons overlap during August and September and similar to hefty people buying 1 ticket on an airline, there’s no escaping the squeeze. How they thought this was a good idea, the world may never know. But the city goes ahead and invests into this futile assumption that if they build another bridge or two, widen up Division and Collins Street, that everything will be just peachy for us all. What they don’t realize is that widening your arteries isn’t going to let the red meat clog them any less, and our city will still have a heart attack every Sunday.

In fact, saying a heart attack is an understatement. A heart attack would feel like pleasant numbness compared to what we will see up here in the fall. Be ready to party on September 20, 2009 because it will be the end of the world, or at least the end of Arlington, as we know it. Regular folks will sit and tell you, “It’ll be okay. The Rangers play at 2 and the Cowboys will go on at 7pm. It’ll be just fine.” But don’t listen to those crazed madmen, as the Borg known as Jerry Jones has radiated their brains with beefy banknotes until it dribbled out of their ears. Let me whip out my crystal ball and picture for you what will really happen.

It’s a hot summer afternoon, just like any other Texan Sunday. Since it’s the 2nd half of the season, droves of fans will be leaving the Ballpark in Arlington thanks to the Rangers losing, because of their pitchers loaning their arms to the 1-armed midget club. It’s as traditional as the sun coming up the next day, and you can set your clock to it. But the fans, for some reason surprised that their Rangers once again threw away a perfectly good season, hop into their cars for the drive home saying, “Man, that game sucked! And they were so good a month ago. Let’s hurry and get home. I really could use a beer.”

Meanwhile true Texans will be arriving on the scene. As any true Texan knows, you are only allowed to do three things on Sunday: go to church, drink beer/party, and watch Cowboys Football. Anything else is just blasphemy. Tons of metal trucks and cars race over to the ceremonial tailgate parties, but as they arrive, all of the Rangers fans will be racing away from their dark loss. In this middle of this mess, you can hear the Cowboys fans to say, “Who’s driving away from the Cowboys on a Sunday? Keeping me from my tailgate party is a sin! And where’s my beer?”

Just as you thought it couldn’t get worse, church bells can be heard off in the distance. All of those nice people that have been going to church all day are now driving home. But the clusterf#ck has begun, spreading out beyond the mere 2 stadiums in our fair city. Slamming their brakes on the way home they exclaim, “I was just in church for 8 hours! Why did God put me in traffic? Somebody get me a beer!”

But it’s all too late now. Thanks to the law of Samuel Adams (Traffic * People^Beers Consumed = Size of Mess), our grand city has now been enveloped into a Black Hole Cluster, slowly spreading at the rate of natural stupidity. It sucks in everything in its path and no one is safe. There will be people walking through the Walmart across the street exclaiming, “I’m in a grocery store. How did traffic get in here? Hey look, there’s beer on sale!” The black hole will have stretched into Lincoln Square, where all the little puppies in the pet shops will be shouting “Bark! Woff woff arf? Yaaar!? (Translated: We don’t even drive cars! How did we get into a traffic jam? And who put beer into our water bottles?)” But in black holes, nobody can hear a drunken puppy scream.  Homeless people will crawl from their derelict shelters mobbing the people stuck in their cars and trucks asking, “Please sir, could you spare me some change? Oh, can I also have a sip of your beer?” Priests will be coming out of their churches exclaiming, “From the book of John, Chapter 3, Versus 3-5: Thou shout avoideth traffic, thy work of the devil. Thou shall repent by giving me 2 Hail Mary’s and a brew.” And you can hear small voices coming from the stadium planning office saying, “Wow, this was a great idea! Nobody can get anywhere! Too bad I’m all out of beer.”

As the entire city is at a standstill, drinking their beers and cursing the traffic, one lone man steps into the epicenter of the chaos: Princess Tony Romo. Walking out onto the field at the start of the game, he throws a good pass and takes a hit like a man in the same play (something which never has happened before). Thanks to those new High Definition TVs that can be seen from space, everybody is able to see this once in a lifetime event causing them all to gasp in awe at the same time, sucking all of the air out of Arlington and imploding the heads of everybody within a 50 mile radius like a Total Recall rerun, which shatters part of the atmosphere due to lack of air pressure, forcing the Earth to veer off course and straight towards the Sun to doom us all!

So there are many lessons to be learned here. No matter how much they pay you, never put 2 stadiums right next to each other if their schedules overlap. The cost of a beer at either stadium is worth a six-pack at the store. If you are stuck in a cluster, Walmart makes for great parking. And most of all, if the world ends on September 20, 2009, you can all blame the city of Dallas .

I’m so angry from writing this; I think I need a beer…