Why Do Software Projects Fail?

Posted on by
Reply

Today I was reading an article titled “Why Big Software Projects Fail: The 12 Key Questions” by Watts S. Humphrey. It was a very interesting read indeed and inspired me to follow up on the subject.

It is no secret that the history of software development is littered with colossal failures. Reasons and excuses are many and you can find them all over the place. Probably if you lift a rock in the desert you’ll find an excuse for a software development project failure underneath. There are cases where the excuses are valid but truth be told, in 99% of the cases the reason are simply human factors.

According to Watts S. Humphrey, the main problem with software development is managing visibility. In his own words:

Why Is Management Visibility a Problem for Software? The problem is that the manager cannot tell where the project stands. To manage modern large-scale technical work, you must know where the project stands, how rapidly the work is being done, and the quality of the products being produced. With earlier hardware-development projects, all of this information was more-or-less visible to the manager, while with modern software and systems projects it often is not.

Some people might argue that this is an overstatement and at some point it is. Managers usually have a rough idea of where a project stands although not with the precision required by large projects. With small sized projects this is tolerable and these kinds of projects are usually a success, however as Humphrey say: “… as projects get bigger and communications lines extend, precise status information becomes more important.”

Along the same line we can say that another big part of the problem is change management. When we go to a car dealer to buy a new car we can tell him the brand, the model and what accessories we want and he will probably give us exactly what we asked for. Lots of the stuff we buy in the real life is like this, we just acquire a product that someone else made for us to consume.

With custom software development, most of the times this is not true and we can’t apply the same rule.  We have to think of a software project as a living entity that evolves and changes with time. What was right today might not be tomorrow, the requirements change as our clients’ business needs change. If we don’t take this into consideration most likely the project will fail.

So, if things are like this; if the statistics are against us and most of the projects fail, are we all doomed? Should we pack our bags, go home and forget about software? Sometimes I tempted to do so and open a grocery store in some tiny town in the country… but I digress.

The real question is what can we do to win this fight and deliver a successful software project? This might sound naïve but I think the answer to that question is with trust and a sense of community and collaboration. All the parties involved, including managers, developers and client all alike need to trust each other, stay in permanent communication and have a strong commitment towards a project success. If any of these conditions isn’t met the project will most likely fail.

In my next blog post I’ll talk the current trends in the software development to help avoid these common problems, live long and prosper in this business and don’t die of a heart attack when you turn 35.

- Pablo Bessone

Annual Bootstrap Extravaganza!

Posted on by
Reply

Last Thursday was Bootstrap’s annual NYC party to celebrate the new year! This year, the party was held at the Housing Works Bookstore Café and was catered by the Works Catering and Roosevelt Dime provided live music.  The space was incredible, the food was delicious and the company couldn’t have been better!

Bootstrap had much to celebrate for 2011 including:

  • Addition of new clients and continued work with existing clients
  • Opening operations in Buenos Aires
  • Hiring of more than 15 new Bootstrap employees world-wide
  • Launch of our new website
  • Moving into a new office

This year’s celebration also included the innagural Bootie Awards! Categories included, Most Adventurous Facial Hair, Most Likely To Be Seen Deskercising, Most Mysterious Employee, among others!

Thanks to everyone for making 2011 one of the best years yet for Bootstrap. Looking forward to an even better 2012!

Click here for all the photos!

The Next Phase is Not Web 3.0

Posted on by
Reply

O’Reilly Media’s Web 2.0 Summit, which took place over the last few days in San Francisco, got me thinking, why is the web still only in version 2.0?

Tim O’Reilly himself coined the phrase Web 2.0 back in 2004 for his first conference of the same name. It was defined by an evolution in front end technologies like AJAX and bubble letters, back-end technologies like web services and RSS feeds, and business models like crowdsourcing and software as a service.

So given that we’re 6 years in to Web 2.0, when will we get to Web 3.0? The answer is never. No one will ever start calling it Web 3.0. For one thing, it’s not catchy. Web 2.0 has a certain ring to it that Web 3.0 doesn’t. Also, I think it will be difficult for people to come to a consensus on when technologies have evolved enough to move to a new version number. Web 2.0 was coined by a single person. Web 3.0 would have to be more organic. We much more likely to describe future “versions” of the web in descriptive phrases rather than numbers.

Tim Berners-Lee has always been against this nomenclature anyway. His alternative to “Web 2.0″ was the “Read/Write Web,” because of the way in which users became empowered to contribute en masse to the data on the internet. And in 2006, when asked what Web 3.0 would be, he said that a component of it would be “The Semantic Web,” or “a web of data that can be processed directly and indirectly by machines.” In other words, a web in which the machines can glean meaning from the data, in addition to simply manipulating it.

But I would argue that we are already at the next evolution of the web, and yet it’s not about semantics. It’s about context. This new phase of the web has largely been catalyzed by two breakthroughs: advances in the power and reach of mobile computing, as well as what Mark Zuckerberg calls “the social graph.” Both of these lend not meaning but context to data, and that is a very powerful thing.

Mobile devices can contextualize data around locations, photos, video, and audio (among other things). And of course the social graph connects data to people. The “Internet of Things,” as it continues to grow, will increasingly connect data to objects (shall we call it the “object graph?”). Although context is a step in the direction of semantics, we are still a ways away from getting machines to the point where they can interpret meaning from this data.

Indeed the “web” isn’t even about machines anymore. What was once a network of machines connected by wires is now a network of people, places and things connected by context. There is a new network growing atop the old.

Perhaps the semantic web will come in version 4.0 (although we still won’t call it that). But I think the best characterization of the most recent evolution of the web is the “Contextual Web” (I am not the first to call it such). Twitter, Facebook, Foursquare, the iPhone, Android, and many other prominent technologies can fall under this term, and I think it best describes the current proliferation of mobile and social technology that is spawning so many new and interesting businesses.

read more from Jamie at jamieforrest.com

Minimizing Agony, Maximizing Pageviews

Posted on by
1

On Wednesday at the Launch Conference, travel search engine Hipmunk presented a new mobile version of their web app. But that’s not what I want to talk about. I want to talk about Hipmunk’s general approach to solving the problem of airfare search, and how it might be applied to other problems.

The genius of Hipmunk is in their “agony” algorithm, grounded in the key insight that when people search for airfares, price and departure time are rarely the only considerations. What people really want to know is how agonizing the trip will be, measured as a combination of price, duration, and number of layovers. So Hipmunk sorts your search results by this “agony” score (in descending order of course). Simple. Brilliant. There’s so much agony in the world; what else could this model be applied to?

The first thing that jumps to mind is turn-by-turn directions. Most navigation apps provide routes that optimize for distance or time, and in some cases by real-time traffic patterns. But there are a lot of other factors than can contribute to one’s agony while driving. For instance, given the choice, I’d much rather drive a scenic route than an interstate, but likely only if the scenic route isn’t orders of magnitude more time-consuming. Or maybe I’d like to drive a route with better food options than Shoney’s and Roy Rogers. Transit directions could also benefit from applying this model. I’d much rather take a trip that involved a transfer if the two subways were less crowded than the one, provided the trip duration wasn’t significantly longer.

Another great application of the “agony” model would be a site that helped you decide whether or not buy something online or at a nearby store. The algorithm could factor in a combination of item cost, shipping cost, shipping duration and return policy of the online option, and compare it to the item cost and travel distance to a local store that carries the item, as well as the real-time availability of that item in the store’s inventory (Milo.com is working on this last problem).

Sorting by “agony” factor is a powerful idea, and one that is quickly letting Hipmunk soar to the top of the travel search business. What other problems could you apply this model to?

read more from Jamie at jamieforrest.com

Designing for the Web

Posted on by
Reply

One of my favorite parts about being a designer is communicating an idea or getting a certain point across to the audience. Designers translate a thought into a visual representation with the intention to help people understand that initial thought.

Designing for the web is a particularly challenging but interesting process. Although I’ve been a graphic designer for years, my background is in illustration; painting and drawing specifically, occasionally using a computer for slight enhancements. When it comes to artwork I’m pretty much a pen to paper kinda gal. In any type of design though, whether it is with a mouse and pixels or a paintbrush to a canvas, the designer has to take into consideration all aspects of good design. Knowledge of composition, color schemes and contrast (among many other skill sets) are integral to being a good designer.

Yet, when it comes to the web, all these skills are relative to a designers’ knowledge of interface design. In an illustration, the audience is receiving the information being passed on by the artist and interpreting how they want to. On a website, the user is receiving the information, and when it comes down to it, there’s only one interpretation possible. It all depends on how intuitive the design is in order for the user to get that information properly.

The key to a great website isn’t how bright and crazy the design is, or fancy animations and tons of unnecessary features. Its how understandable it is to use, and how enjoyable the experience it is. Of course visual design (colors, typefaces) plays into the enjoyment factor, but really, you want a user to come to your website, know what they want to do, be able to do that, and come back and do it again. Hopefully somewhere in between that, they’ll tell someone about your site too.

When I design for a site here at Bootstrap, I’ve most likely spent a lot of time on wireframes (or someone else did) and I have the interface issues solved. Sometimes, for personal projects like artist portfolios, especially, I just jump right into the designs. When that happens, I am still always keeping in mind the importance of the user, and making sure that anyone who comes to that site can navigate it easily and successfully. Following this, certain things in a design are going to be adjusted, or compromised. For example, if you have some awesome photographs that you want to display, it all depends on what your site is for. If it is a photography portfolio, by all means, those photos should be the main attraction of your website, and of course be larger in proportion to any other elements on your site. On the other hand, if you are a company that offers special services or products, you may have other information on your site that is much more important than a nice picture. Especially if you have an ambiguous company name or logo, users are going to want to find out what you are all about, immediately, and if you have an enormous photo pushing all your content below the fold, it is going to effect the user’s productivity and impede on their overall efficiency.

Certain color schemes also have to be taken into consideration. For a print poster advertising a huge sale, bright colors and large text can be incredibly effective, especially when people are viewing from a distance. On the web, readability is crucial. Sure, there may be important things you want to ‘pop’ on the page, but if it is taking away from the overall goal of your user, there are plenty of other ways to emphasize certain elements than using bright neon colors and enormous text. If a site is going to have a lot of text, such as a blog or a web based newspaper or magazine, there are certain color schemes you must follow. Typically, light text on a dark background is looked down upon on the web, because of the ‘glow’ that can occur around letters, which can be incredibly distracting if the text is smaller and more compact. On the other hand, it has been said that if someone is staring at a screen and reading for a long time, having a light background can be straining on the eyes because its like you’re staring at a bright light for hours. Either way, taking into consideration the color and type of text you use is incredibly important. Put yourself in your readers’ eyes, would you want to be reading neon green text on a hot pink background? I don’t think so.

All that being said, design and the web are constantly evolving. With all the possibilities of programming, designers are now more able to stretch their creative muscles and really experiment with new elements and designs. As exciting as it is, we still have to remember that we are designing for an audience and their experiences are what make us grow.

Halloween Fun at Bootstrap!

Posted on by
Reply

Bootstrap’s New York office got into the Halloween Spirit on Monday!  Congratulations go out to Kate Baldwin who was the winner of our costume contest as punk rock Miss Piggy and to Elizabeth Muigai who guessed that Bootstrap ate almost 25lbs. of candy out of the cauldron during the month of October.

I would also like to thank everyone all others who donned a costume or wig for the day. It was great to see everyone get into the spirit!

Easter Eggs

Posted on by
Reply

Part of developing a site or deliverable is adding fun easter eggs in your work. For the longest time, “Rick Astley” has been the ongoing username used in our wireframes. Sometimes, when a video placeholder is needed, you would even see the first frame to Mr. Astley’s iconic video.

When we developed our redesigned website, we also had a bit of fun.

Doctype
Back in the days of HTML4 (although most people are still living in it), it was required to declare the DTD (Document Type Declaration) after the “public” keyword. However, this is optional for HTML5. These days, the only thing we care about is to declare the doctype at all, just so Internet Explorer doesn’t drop into quirks mode:

<!doctype html>

So now, the quotes after the public keyword can be customized to however you like. As an example, if you go to html5boilerplate.com, you’ll notice that they customized their doctype with a star.

Go ahead and check out the source for our site, as well as this blog. Here’s a hint of what you’ll find:

Shake It Up
Another great feature that gives a new dimension of interactivity is the “devicemotion” event, which can detect the x/y/z motion of a device with an accelerometer. On your iOS, Android, or even Macbook with an accelerometer, try shaking your device on our “Who We Are” page.

Jeffrey Chew
Director of UI Design and Development

This Piece of Technical Writing Has Been Written By Me

Posted on by
1

In my role as a business analyst at Bootstrap I see a lot of technical writing, much of it terrible. For some reason, people whose job it is to be precise and logical often fail to do so when the language of expression is English, rather than Java. While the problems in technical writing are varied, the offense I most often see is overuse of the passive voice.

For those who don’t remember their junior high school grammar, passive voice is a grammatical construct in which the object of a sentence is repositioned as its subject. “Tom throws the ball” is active voice, while “The ball is thrown by Tom” is passive. The use of passive voice in itself is not grammatically incorrect, but it often weakens the clarity of the writing by obscuring who or what is doing the action in the sentence.

Technical writing is a veritable breeding ground for passive voice proliferation, in many cases because the actors in technical writing are not tangible. The actors are software code, or systems, or networks. My phone today popped up an alert that said, “The server cannot be reached.” Who exactly is the one not reaching the server? Is it the phone? Is it the app I was running? Is it me?

But just as a writer would avoid passive voice in “normal” English prose, so too should a technical writer avoid it in his work. Phrasing technical ideas in the passive voice dampens the agency of the thing doing the action, making it seem unfamiliar and disembodied. Technology does things. To render technology in the passive voice is to distort its power to create change.

This is especially evident when technical writing refers to error conditions, as in the case of the alert above. It’s almost as if the authors of the software were deflecting blame away from themselves with the message, “The server cannot be reached.” They could just as easily have said, “It’s not our fault that you can’t access this page. Talk to the dudes who run the server.” (People in IT love to blame the other guy, but that’s a story for a different post.)

It’s never that difficult to clean up language like this in one’s technical writing, but it often requires ascribing some degree of agency to to the technology. Instead of “The server cannot be reached,” one could write it as, “The application failed to reach the server,” or, “The application failed to connect to the server.” If English had a better indefinite subject pronoun, we could even write something like, “One cannot reach the server at this time.”

There are any number of solutions to the problem of passive voice in technical writing. The main thing is to be aware of the easy pitfall, and to think about technology more as an agent of change than as some hidden force behind the things we observe.

read more from Jamie at jamieforrest.com

Redesigning BootstrapSoftware.com

Posted on by
Reply

Over the seven years I spent with Bootstrap, I’ve seen the company grow from a development company, to a fully evolved team that provides everything from well-defined discovery, smart development, and a refined maintenance/support process. During that time, I was able to add usability and information architecture to the many services that Bootstrap provides today. However, one of the bigger milestones for both Bootstrap as well as my career was the birth of the Creative team last year.

As with any client’s redesign (or initial design for that matter), it’s important to understand the business goals, objectives, identity, and overall brand. Our creative process includes many steps and deliverables in order to identify these points, as well as a game plan on how to achieve the client’s needs. We deemed Bootstrap Software as a client, and treated ourselves no differently.

The User Experience

As part of our research, we studied the competition as well as applying what we know about our previous site visitors. We identified the target user personas, then began to structure how we want to deliver our message using UX design and information architecture techniques.

In parallel to this, we generated and explored various mood boards to get a better idea of the look and feel we wanted to achieve.

Based on feedback and several iterations, we were able to determine the general feeling we wish to convey to our visitors, as well as how our visitors can find the information they need quickly. This brought us to two different design directions; circle and square.

As with any design process, iterations can conceivably go on forever. We tasked ourselves with defining the pros and cons of each direction, then ultimately deciding on one. From there, we took the things we liked from the other and applied more detailed iterations. The end result is the site that you see today.

Interaction Design
The look and feel is only half the battle when it comes to design. What the user sees has been established, now how about when the user starts clicking around? One of the continuing mantras said throughout the discovery process was “no flash”. The whole Internet industry is abuzz with “HTML5”, and we wanted to flex our muscles as a company to show some of the latest and greatest your browser has to offer.

It’s easy for a designer to get carried away with how a site should behave in their mind. This is when it’s important to sync with a front-end tech lead on what we can and cannot do, according to the browser scope of the project. Storyboarding the site interactions is important to convey these ideas, either by conceptual or detailed wireframes.

In the past, we were accustomed to developing the “pixel-perfectness” from browser to browser. However, the industry is gradually seeing the importance of delivering speed and good UX over visual or functional consistency. This is why progressive enhancement is Bootstrap’s approach today over yesterday’s idea of graceful degradation.

Progressive Enhancement
As a front-end developer, I was no stranger to browser sniffing and conditional behaviors. I still cringe when I think about how much Netscape 4’s DOM differed from Internet Explorer. As part of progressive enhancement, the idea instead is to set a baseline that all browsers can understand, then go from there. We use a couple of tools in order to achieve that “reset”, then feature detection:

Because we want to develop our site using HTML5 semantics, it’s great that Modernizr includes an HTML5 shiv that will allow “oldie” browsers like IE6/7/8 to interpret tags like HEADER, NAV, SECTION, etc. For anything more complex, we use Modernizr’s feature detection to determine if the user’s browser can handle certain code. Because our site is almost completely based on CSS3 transitions, here’s one we used multiple times:

if (Modernizr.csstransitions){
     // do some awesome stuff
}

CSS3
Everyone talks about HTML5. In layman’s terms, when a user sees something that is accomplished without flash, it’s easy to say “oh, that’s HTML5”. Well, that’s partially right. By definition:

HTML5:
(n) 1. The next version of HTML. Its core aims have been to improve the language with support for the latest multimedia while keeping it easily readable by humans and consistently understood by computers and devices

In general, HTML5 is the combination of HTML, CSS, and JavaScript. A good chunk of the “magic” in Bootstrap’s new site is in CSS3, both rendering and animations. Because we chose the “circle” route, the site heavily uses rounded corners on elements. If you look at the http requests on our site, the only images that are loaded are the employee images, carousel images, and logos.

Another added benefit of CSS3 transitions is that animations are hardware accelerated. If we tried to achieve the same kind of animation on the “Who We Are” page using JavaScript, the page would get choppy. We made use of the “translate3d” attribute for transitions especially so webkit browsers will take advantage of the acceleration. Try using one of the dropdowns, then repeatedly clicking one of the options.

Google Chrome Frame / IE[x]
The benefit of progressive enhancement is that the site will still generally look fine even on the most stubborn of browsers (i.e. IE). Short of forcing the user to switch to a different browser entirely, another option we give our users (for those viewing our site in IE7 or below) is to install a plug-in called “Google Chrome Frame”. This was developed by Google, and is a plug-in for Internet Explorer that generally makes it behave like Chrome. The added bonus is that it automatically updates, just like Chrome. It installs in seconds, and the user can see all of the new and fancy things that Chrome has to offer, while still browsing comfortably in a browser they have grown used to using.

Although realistically we still need to support the browsers our clients task us to develop for, we hope that this “solution” catches on. As we’ve developed more HTML5-friendly sites, the more we’ve realized that IE[x] is the new IE6. Paul Irish, one of the developers on the Google Chrome team and leading front-end developers of the industry, has a great write-up on this.

Responsible Web Development
Whether if we’re developing a generally small site like ours, or an enterprise level web application, we always hold ourselves to the best practices of web development. The front-end in particular is rapidly becoming more robust, and can become unwieldy and harder to maintain when losing focus on how it is built. And with this great power, it means that much more responsibility that falls on the developer.

Wrap-up
Any project can easily stray off the path, especially in our own site redesign considering this project has a very close emotional attachment to all members involved. That is why our process played a crucial role in moving forward with our milestones and eventual site release. It also doesn’t hurt to have a stellar team working beside you every step of the way.

Jeffrey Chew
Director of UI Design & Development