StandardPixel.com

I see a lot of potential around me. I always want to take apart or tinker with some thing or process to improve it. All of these ideas create a growing inventory of things to do. All of that Getting Things Done (GTD) talk that I started to notice couple years ago, was an eye opener. Suddenly everybody had great ideas to help me organize and plan. Now in 2008, armed with A note pad, an Inbox with 0 items in it, and a Remember the Milk account, I am finally starting to get things done.

In the first few iterations of my GTD approach, I would just keep adding and adding things to my ToDo list. When something was added, I would give it a priority and never look back. Inevitably, I would just start ignoring things and move on to the one that I really needed to do when I would look at my task list. Turns out one important thing about getting things done, is coming to terms with the fact that an idea you had last week may not really make sense this week or a priority from last week may not be the same. Now I have modified my process of adding to my list to also include a quick audit of the items on the list. I always end up removing one or two things.

This lesson should not be lost on those of us that develop software when we are at work. There are a lot of ideas that you can come up with that can be added to the idea inventory for your project. What makes this harder is that you have other groups that are hired to add to your inventory as well. QA will keep your inventory full of bugs to fix, Designers will keep it full of crazy new patentable interfaces, and Product Management will keep coming up with more features that MUST be there. Every time something is added to the mix a full audit and re-prioritization needs to be done to keep the inventory manageable.

PHOTO CREDIT: Uploaded to Flickr on May 26, 2006 by kogakure.

There is a tendency in larger software organizations to value “hard work”. At face value, this makes sense. We all want to be known as hard workers. Some of us love to be known as the hero on the team that can stay up the latest and check in the most code. In truth, a “hard worker” can meet a goals, but this has no reflection on how innovative they are.  This is because, we are not factory workers, we are creators. 

The process of creating is vastly different from that of working on a production line. Creators bring things into existence that did not exist before. This creative process is important to protect because without having a prior example of what is to be created, time must be invested to dream up every possibility and make sure that the solution that is used is the most appropriate. The need to be seen as a hard worker redefines our idea of a goal from the satisfaction of finding the most appropriate solution, to being the first to make something that is good enough to pass tests. I believe that this is what makes  a lot of software from companies more mediocre as time goes by. This is also a reason that a lot of corporations are not inspiring places to work. The book Peopleware goes into greater detail into this subject then I should, so if you have not already, give it a read.

No, I don’t want to sound hopeless. In fact, I am trying to figure out the cure for this tendency. Respecting the fact that software will be less valuable if it is rushed, requires a definition change of the word management. I think that a lot of managers still think that software can be planned beforehand, handed off to be designed, passed to engineering, then put through testing and launched. This is known as the Waterfall approach right? So is Agile the cure? Maybe it is, but unfortunately, a lot of teams have implemented a half-assed Agile process to a team without proper agile training. These teams then get convinced that Agile does not work because it did not work on their team. Unfortunately, Agile has been rendered powerless in some companies for some pretty unfair reasons but powerless just the same.

If you take the time and think back on your career, have you ever had a project that went smoothly? A project that did not go past the deadline? or require a crazy amount of hacks to get it out on time or close? For those of you who would say no, I am sure this was not for lack of hard work and reasonable preparation.

In web app development, as in anything else you have to have a balanced set of requirements. As the business folk have always said: “Cost, Quality, and Speed - You only get two”. It just seems to work out that way. Now for us in web development we have a different three to choose from: Speed of development, speed of served product, and flexibility of design. Each needs attention, but too much attention too one will deplete the others and lead to a poor product. Lets inspect each:

Speed of development

An app can not be built in a day, but it should be built in a few months. By the time an app gets through design, development, and testing a lot of things can change. I don’t know anybody who has worked on a long or short term project that did not have one or two requirement changes after development had begun. This is why we use Scrum right? Obviously if the reality is that requirements will be added during development, it makes a lot of sense that the longer you are developing, the more last minute changes you will do. However, if you are able to cut the development time, it is easier to convince the business that their super important icon color change can go out in the next sprint.

Speed of served product

Does it scale they will all say. Will your app be fast enough and your servers be strong enough to handle a lot of users and / or slow clients. Some argue that Frameworks that make development easier are less flexible and harder to scale. To be completely honest they are right but it is important to measure each and decide if some sort of balance could benefit you more or at least break even.

Flexibility of design

It is important for the app to be flexible enough to meet user needs and have an enticing interface. This one is interesting because not too long ago I would have counted this as one of the two most important along with speed to develop. That is until just before I started to get inspired to write my post “SproutCore is a chainsaw and YUI is a paring knife“. That is when I realized that a Web App is quite different from a web site and really should follow more closely the rules of a desktop app. In desktop apps we are better off using common OS interface elements that people have grown accustomed too.

Which two do I choose

As you may conclude from the last paragraph, it depends on wether it is a web app or a web site. For a web app, I would choose speed of development and speed of served product as these tend to have a need to make it too market as a complete finished product in a short time-frame and rely on the back-end heavily to process data. Also, consider this quote from UPA – ”Consistency is one of the most important aspects of a repeatable user experience. If users know what to expect, it will be easier for them to build a conceptual map of what should happen next“. On the other hand a web site has a different purpose and I would trade speed of served product for flexibility of design as the idea is to entice users to enter and look around.

Last week, in an effort to meet an impossible timeline, our team was asked to make a few changes. We were assigned 7 people from other teams. We also were asked to stay some extra hours and work the weekend. Our commitment was amazing. We worked for an entire week of 12 hour days. The lack of ego and complacency remarkable. This was not by any means my ideal way to spend a week but I understood what needed to be done and the consequences if the goal was not met.

Introduce 7 new people

to a team that has been working together and there are bound to be a few bruised egos. Think of the actors involved

• Heros - some people love to be the one person on their team that knows one subject better then anybody else. With 7 new people there are bound to be one or two people the will match or exceed that skill.

• Black Boxers - Some people just don’t like to collaborate. Maybe they are trying to hide a perceived or real lack of talent or maybe they are just anti-social.
• Power Grabbers - There is usually one or two on the team that aspire to manage the entire team. They can be arrogant, nosey, and pushy.

All of these types are toxic to a teams ability to gel. I am not absolutely sure how, but we seemed to have none of these on board. Sure we had our conflicts but everybody was genuinely glad to help. This is more impressive considering most of the new people were traveling from our main office, and are now more then 5 hours away from their homes and families. 

Management started off on the right foot,

We all got the impression early on that this was a short term push for an important goal. Most of us felt that the request was made with respect and we saw our management committing themselves at the same level. Every hour that we were there we knew that they were there too. Now beyond that they picked up our lunched, dinners, snacks, and even threw in 30 minutes of seated massage with the professional misuse. These gestures did a lot to keep the 12 hour days from becoming stressful, which would have been very easy.  

Agile methods were employed

in one way or another. It was not a proper Agile project but we had tasks, a burn down, standup meetings, and most importantly a time box of one week of which we all were made well aware. These key articles of Agile were the keys to any successes that week. Many to my team mates had never been on a proper Agile project. I do not think that anybody could deny the positive affect that they had even if they never credit it to Agile.

Lastly, sense of purpose

was the jet fuel that propelled most of us through the week. We were obviously convinced that the work that we were doing was going to affect the bottom line in more than a usual way. There was a sense of pride. 

This pace was astonishing though not as all sustainable.

By the final day of the week I did start to see cracks appear. Everybody on the team was obviously exhausted and creativity was starting to wane. The next week, (yes this one) seemed less productive then any before. This was not a bad exorcize though, we managed to build some strong relationships and get a lot of work done in a short time. I am not sure if I would recommend this as a way too save time because it seems like there will be more time lost as the team recovers their motivation and creativity. It is however a great way for a new team to gel.

One thing that can render any perfectly executed SCRUM planning session useless, is a broken development environment.

Once the backlog has been prioritized, and the team had generated a sensable amount of stories and tasks, teams are energized to start moving those tasks to complete. What is lost when that developer goes back to their desk to find themselves without a db to code against or a login server that just doesent work? A Lot!

What we stand to loose

Sure we all know that these type of outages will cost us backlog, which will translate to time subtracted from our sprint. But what we should fear more is the loss of the momentum that the developer had when he/she finished sprint planning. The developer is now frustrated and will likely not find that lost level of inspiration again. At least not easily. Lets be honest, a developer has very few actual hours of productive time in a work day. Take an avarage 8 hour day and subtract meeting, email, IM, and phone distractions. Lets also consider that most people need a fair amount of time of immersion to reach their most creative state.

Tools make all the difference

All of our distractions require us rely on our tools to be there and ready to go when we need them. This means that we need to spend some serious time planning our tools and how each developer will interact with them through out the sprint. Designers shouldn’t need to interact with code to create designs. Back-End engineers shouldn’t need to hassle with CSS. Also, Front-End engineers shouldn’t need to configure XML files and compile. We have the technology available to make real use of the MVC pattern yet I have witnessed a lot of projects start out with the assumption that everybody can easily run that ANT script or whatever. I can also say that every time I have see this I have seen time being wasted on complex troubleshooting by smart Front-End Engineers and Designers that have been reduced terrible Java troubleshooters.

What to do? What to do?

Excuse my possible ignorance, but in projects where the heavy lifting was done by java and accessed through the magic of web services by clients written in PHP or Ruby on Rails. It cant be a coincidence that these projects had far fewer wasted hours. The pieces are smaller and easier to manage. Each person is working on a smaller chunk of the bigger project that he/she understands enough to easily fix problems. I am sure that somebody would argue that there is far too much processing overhead in such a configuration but i wonder how that weighs against the lost time and creativity without it.