Green living for busy computer nerds

Check out my list of tips for green living especially suited for those of you who spend most of your time in front of a computer. The list will not require you to make big changes in your life or invest in new expensive stuff.

• Use both sides of paper when taking notes or when printing from your computer. Most printers have a double sided print option.
• Buy clothes made from natural fabrics like cotton, wool or silk.
• Turn down the brightness of your monitor.
• Don't buy high tech fancy clothes made for sub freezing temperatures unless you are going to the North Pole. These clothes require both non eco materials and non eco production methods.
• Read your PDF-document on the computer, tablet/iPad instead of printing all 200 pages.
• Have a personal mug at work. Don't use dispensable paper or plastic cups.
• Don't throw a way clothes and other stuff. Give them away.
• When buying stuff, choose the one product that comes in the least amount of plastic packaging.
• Switch your computer all of when you go away for days.
• Line dry your clothes rather than using an drying machine.
• Unplug the cell phone battery charger when you're not charging.
• Turn of the lights in the rooms you are not in.
• Put the computer in standby when you leave.
• If you use a screen saver use a blank all black background.
• Stop buying stuff you don't really need. To help the economy buy services rather than physical products.
• Don't leave the tap water running while brushing your teeth.
• Before you decide to buy a new computer make sure you have tuned and cleaned up your computer making it as fast as it can be.
• Skip rinsing your plates before putting them in the dishwasher.
• Turn off all the light when you leave the apartment or your work.
• You don't need to switch to a new cell phone every 3 months?
• Have power saving enabled on your computer.
• Lower your winter heating and put on some more clothes instead.
• Get more energy efficient light bulbs.
• Use less water when taking a shower.
• Walk or take the bicycle rather than the car if you can.
• Buy used, second hand stuff.
• Bulk purchases.
• Travel less. Use the telephone or online meeting and conference services.
• Reduce junk postal mail.
• Buy locally grown food that has not been shipped from the other side of the world.
• Don't throw away old cell phones and other electronics in the trash can.
• Share stuff instead of buying the same stuff as you friends or neighbour.
• Buy fewer products for Christmas and birthdays; instead buy services/adventures/experiences.
• Cook food with a lid on the casserole.
• Switch from black on white text to white on black text on your monitor if you can change the desktop, your application colours. This can save up to 25% electricity usage.
• Put on some more clothes at home instead of heating the apartment.
• Choose online services that have green data centres.
• For your next computer, consider a laptop instead of desktop. A laptop uses much less electricity.
• Buy recycled paper for anything from toilet paper to printer paper.
• Do you really need a big house and a big car?
• Write notes on your phone, tablet etc. we're consuming billions of disposable pens each year.
• Don't pre-heat the oven. Turn the oven on after you put in the dish.
• Before buying a new computer, consider upgrading the hardware.
• Make less noise. With less noise others around you can think more clearly. More clear thinking means more effective work. More effective works means less energy needed to do the same work.
• Download e-books rather than ordering books from Amazon that has to be shipped.
• Make better plans before going somewhere so there is less detours.
• Use matches instead of lighters.
• Have fewer coins. Having a lot of coins prevents them from being circulated and this result in more coins having to be minted. Producing coins takes a lot of energy.
• Buy less bottle water/soda, or at least buy a local brand.

Benefits of using OAuth as your login provider

OAuth has become a popular mechanism to facilitate sharing of data between applications. Another way to take advantage of OAuth is to use it as your login provider. In this post I'll discuss the pros and cons of using it as the login provider for your web application.

To use OAuth for login, all you have to do is to use some OAuth code library and create a consumer application that will connect to an existing OAuth provider such as twitter, linkedIn, Facebook etc. Store the OAuth token in your database, use cookies to save the user login state in the browser and most of the work is done.

The alternative to using OAuth as the login provider can be to implement OpenId or some proprietary login mechanism. Here are some advantages and disadvantages compared to developing or buying a component for login and profile management.

From the end user's point of view:

Advantages:

• You don't have to create another profile on the net.
• Fewer passwords to remember.
• Do not have to submit a password to your application if he / she does not completely trust us.
• User can prevent access to the application from the OAuth provider.
• Allows for exciting extra functionality and synergies when taking advantage of the social graph and other data and features made available by the OAuth provider. This may provide much added value.

Disadvantages:

• User can not tailor the profile for your application (would require additional development).
• Can be a bit confusing for the user having to create an account with OAuth providers if he / she does not have an account there already.

From the organization's point of view:

Advantages:

• Save time on developing authentication, display of user profile and social interaction as friends lists, status updates, profile, photos, etc.
• Do not need support for password renewal, forgotten password, authentication of users, and support to let users remove themselves from the service, etc.
• Lower risk and fewer bugs in connection to authentication when using a ready-made proven API.
• Low-risk for ID theft, etc. The service already has good support to prevent this. Authentication takes place at provider, the OAuth tokens is encrypted and not in our application.
• If the OAuth standard is extended with support for info cards or other functionality in the future, it might easily be supported in your application.
• Easier to manage / maintain / configure than forexample extranet login models with mixed authentication (Forms based SAML etc.)
• Less data to store on your servers.

Disadvantages:

• No connections to existing user accounts e.g. in Active Directory if needed.
• If the remote service is down you have no login (unless the user is already logged in. The authentication cookie is valid).
• Requires some logic if you will allow the user to log in with multiple OAuth providers.
• Maybe you (or your company or brand) do not want to associate your self with certain OAuth providers.
• Maybe the end-user do not want to share his OAuth provider data (LinkedIn / Twitter / Facebook / Yammer, etc) with your application.

More information

Technical description of OAuth

• oauth.net
• dev.twitter.com/pages/auth

Sample application that shows how login with OAuth in practice

• www.twitarcade.com

SharePoint or Asp.Net MVC for building a new and simple web site

I was recently on a project where we were faced with the choice of what platform to base a scoped down prototype web site on. Based on the team competencies and the fact that we had already developed several SharePoint sites for the customer we were basically down to two choices, SharePoint or developing an Asp.Net MVC site from scratch. I consider Asp.Net MVC superior to Asp.Net so a regular Asp.Net WebForms project was out of the question. SharePoint is mainly a collaboration solution best suited for Intranets and portals. Even so, many companies use the platform for their company website because of the growing amount of SharePoint developers and other benefits of the platform such as extensibility.

The purpose of this blog post is to share knowledge for others who might be faced with the same choice of using SharePoint or Asp.Net MVC for a very small web site with few requirements.

About the team
We were 4 developers, a scrum master, a part time interaction designer and a part time graphical designer on the team. None of the team members were SharePoint or Asp.Net MVC specialists. None had any experience worth mentioning on SharePoint 2010. The average experience in years with programming of the team members were less than 10 years. Most had worked with SharePoint for some years but none of the team members had in-depth expert knowledge on all sides of SharePoint development.

A short note about the scope of the project
Time span of the project was about 2 months including planning, design, development and testing. Without going to much into details, here are the features of the site:

• Integration of some external social media widgets.
• Very basic publishing of simple content.
• Branding and fancy visual design.
• Some commenting, mailing list sign up and feedback features.

The site was a pilot project so we did not have strict requirements on quality assurance etc.

Platform choice
The decision was to use SharePoint as most of the developers were more familiar with SharePoint over Asp.Net MVC. The decision was inline with the company IT-strategy and most of the developers were keen on trying out the new SharePoint 2010.

Experiences
At the time of the project it just happened that I was starting a new hobby project using Asp.Net MVC on my spare time so I had the opportunity to compare SharePoint and Asp.Net MVC development side by side. The two projects were similar in many ways. In the comparison below I only discuss issues that are relevant to both platforms. Many of these problems have also been encountered in previous projects so they might be said to be typical problems you might expect to run into.

Problems we encountered while starting a new SharePoint 2010 project

• We had to switch to a new development environment and install Windows 7 since SP2010 requires Windows 7. Installing Windows 7, setting up SharePoint and configuring all your nice to have software typically takes two days.
• We later got licensing problems for the OS and Visual Studio. This is not a big problem but all of these small non-code related things combined make a lot of noise.
• SP Feature mess: We had trouble setting up page layouts. It kept getting ghosted automatically. We found out that some meta tags attributes on the page layout caused it to automatically getting ghosted during deployment. This resulted in several wasted dev hours.
• SharePoint has a lot of built in JS such as the init.js file. One of the social media widgets we wanted to use would not run along side the SharePoint JS on IE7. Debugging minified widget code and thousands of SharePoint lines was not anything we wanted to do so we had to write some custom code. Again several hours wasted on debugging and custom development.
• SharePoint 2010 still renders bad html and lots of other page elements, js and other markup that is not needed for a Internet facing site. The site even tried loading Silverlight when used as an Internet facing site. Chrome crashed because of the Silverlight plugin. This was fixed by adding a SPSecurityTrimmedControl around the ribbonrow.
• We added several web parts to the web part gallery and we encountered problems that made the add-webpart ribbon unusable since the add button got hidden beneath the ribbon bottom edge on some browsers.
• We encountered problems with the NoteField. We wanted more than 255 characters for the text. When deciding to use the html rich text field instead we had to change the content type and this is not a walk in the park if you have already created some test pages you would like to keep.
• Each time a new content type field is added there's often problems for the other developers. The other developers need to upgrade their solution.
• VS caching bug. While doing deploy from SharePoint within VS we sometimes got this error: deploying Activating feature 'OurFeatureName' ...
• Error occurred in deployment step 'Activate Features': The field with Id {e3575ee4-1b6e-43fc-b243-77f727f33e16} defined in feature {a36d44c1-b523-4235-950a-59ed763d2588} was found in the current site collection or in a subsite. This error had to do with some state being cached by Visual Studio 2010. In this case we had to restart VS.
• SharePoint includes a bunch of js and css files. To optimize page rendering on the client we cleaned up and customized the minimal.master masterpage using editmode controls etc.
• We created XSL for the Content by Query (CBQ) web parts and had to figure out why the CBQ didn't list our pages. Debugging this was time consuming.
• We also had problems with web parts not being deployed because of inconsistencies between .dwp and .webpart files.
• Another problem related to web parts not being deployed had to do with mismatch in the SP2010 .spdef files that might be caused by code merging problems.
• A typical error many do on SharePoint. XSL files packaged incorrectly and end user in anonymous mode don't have access to the xsl.-files and the page breaks.
• Then we had problem with the server. The system was a small pilot project so the server we got was an old outdated server. SharePoint 2010 simply did not run on the old server without extensive reconfiguration.
• We copied a SharePoint feature from another project. We forgot to change a GUID and things just did not work. Debugging, again not trivial.
• SharePoint 2010 does not support IE6 so we had to add a custom warning message for IE6 users. The lack of IE6-support has in retrospective been a problem because it also resulted in down prioritizing IE6 for the front end anonymous view of the site and we have got several complaints from end users who did not understand why the site looked bad on their browser. Also showing of the site is also problematic because the company still used IE6 as the default browser so this lead to embarrassment as we didn't always have control of the installed browser at the location where the web site was presented.
• The page layout or list we tried to add at some point simply would not be added to SharePoint. No easy way to figure out what was wrong with the xml. The schema.xml for a list is not particularly pretty and inviting to work with. There are of course tools to help you with this but the work all becomes very complex and awkward unless this is the only thing you do for a living.
• Then, one of us had problems updating the web.config. Updates did not affect the site on the developer’s machine. After an hour wasted work we found out that SharePoint 2010 use a different web.config file. The new web.config file is under the layouts folder in the 14 hive.
• Next problem; SharePoint redirected mobile devices to a mobile site by default so we had to customize this also.
• Then we got problems on the Publishing Images doc lib. Some unexpected error occurred when navigating to it. Still don't remember what was done to fix it. Simply too many problems and solutions to keep track of.
• We had a lot of static html code that were inserted in content editor web parts. Part of this static html was some javascripts used for client side paging and other GUI effects. In SharePoint this had the affect that the JavaScript altered the content of the web part while the user was editing the web part. When saving the web part the user would be saving the jQuery altered version of the html. To fix this we had to link to a separate file instead and update this one rather than editing the web part content itself. With Asp.Net MVC this would be a simple text field with html. The wysiwyg of SharePoint just made things more time consuming here.
• As with other typical SharePoint projects we had to set up content types, set default page layouts for a page library, what page layouts are available for a site etc. All these things take time to configure in the site definition. This is typically tedious and boring work.

Problems I encountered when starting a new Asp.Net MVC project

• First problem: You code everything from scratch this can be a frightening enough it self. Using some sample code as a starting point might help a lot.
• You get 'Object reference not set to an instance of an object' errors and you can't figure out what is wrong. Asp.Net MVC uses a lot of convention over configuration so there's a lot happening under the hood. Debugging this might be difficult because there a lot of abstractions and inner workings that you might not want to dive into.
• More convention over configuration problems. If you miss a convention or have a convention implemented wrong you will often not get a compile time error message and it’s difficult to locate the error.
• Figuring out how the routing works on XP with IIS5.1 is difficult. Not very intuitive if you are still on XP.

Conclusion
Asp.Net MVC is simply a web application framework. SharePoint is a software platform for collaboration and web publishing and has a rich set of capabilities out of the box. So basically what you are doing in SharePoint development is to customize the existing features, tweaking features, overriding stuff, extending features or even stripping them way. On Asp.Net MVC, on the other hand, you develop the site basically from scratch. For most developers it will be more interesting and exciting to develop something from scratch that they have full control over, not having to abide by the complexities of SharePoint and having to sit and configure XML files all day long.

If you know that you are going to use some built in feature of SharePoint you should consider SharePoint, but if you are not going to use any of the strong selling points of SharePoint such as document management, workflow, compliance, publishing, document search etc you should definitely build it your self.

Benefits of Asp.Net MVC over SharePoint for small and simple web sites

• Asp.Net MVC uses convention over configuration. In most cases this makes development very fast as the conventions reduces the work to be done as well as providing a model (MVC) for architecting and for how to arrange code in a consistent and clean manner that further reduce complexity and speeds up development. Faster development means cheaper development and enables early testing which is important for a prototype.
• You feel more productive as everything you do has a purpose and is directly affecting the solution. Every line of code has direct impact on the actual feature you are working on. SharePoint xml configuration is often used to configure some feature that you don't even need in the solution but you have to configure it anyway just because it's there and available be default to users. A lot of tasks on SharePoint simply seem like a waste of time since you are not working on the required features but instead on removing the features that are not required.
• Most developers find it more fun to write code than writing XML. When writing code you get to be creative and show how good or smart you are. With XML configurations you have to stick to the schema, no room for creativity.
• By using Asp.Net MVC we would have Azure as an alternative or backup hosting model.
• SharePoint development requires a lot of competency. To customize a SharePoint site you need to know web development as well as XSL, the SharePoint object model, feature stapling, site definitions, WSP packaging, SharePoint security model and a bunch of other things. Since very few developers are experts in all of these areas it takes a lot of coordination and teamwork. More dependencies means more development time.
• A part from the social aspects and skills required there are the complexities of the technical solution it self. In general, SharePoint introduces a lot of complexity that makes development less fast. Lots of different type of code in different places, lots of classes, lots of different configurations on different levels, various tools such as STSADM, lots of scripting commands to remember, many folder locations. Lots of concepts and features. If you want to look into the database to try figure out what SharePoint is doing you'll also meet a wall of complexity there also. More complexity equals developer headache.

Benefits of SharePoint over Asp.Net MVC for small and simple web sites

• SharePoint has a lot of built in features, some of these might be exactly what you need. For example, Web parts that can be moved between web part zones was one such feature we made use of.
• As with all IT-projects you must take into consideration future requirements. SharePoint's comprehensive platform might be what you need for your site in the future when your site grows larger and features such as versioning, document management etc may be required.

The big take-away from this blog post

Complexity = more development time.

Requirements reminder

In smaller dev teams in some organizations, small projects often start without much consideration to requirements other than some design sketches. This is a starting point that can lead to several issues down the line, and it is typical when there are no solution architects involved. Once the team (or single developer) has chosen a technical path it might be very expensive to redo the system. The longer the system has been in use by end users the harder it is to rearchitect it.

In this blog post I list typical areas of IT systems. The purpose of this list is to trigger deliberation that can help you formulate a simple requirements specification. 

• Access (Who should have access)
• Accessibility, WAI
• Accuracy
• Adaptability
• Audit and control
• Availability (Service level agreement, downtime)
• Backup
• Branding
• Browser support, clients
• Capacity
• Certification
• Compatibility
• Compliance
• Completeness
• Configuration management
• Configure-ability (can it be reconfigured)
• Correctness (no bugs)
• Cultural and political
• Currency (data is up to date)
• Data structures
• Dependency on other parties
• Dependability
• Deployment (deployment procedures, life cycle turn around and velocity)
• Design (and layout)
• Disaster recovery
• Documentation
• Editorial, publishing
• Efficiency (resource consumption IT, energy, human, performance vs effort)
• Emotional factors (fun, absorbing)
• Environmental tolerance
• Escrow
• Error tolerance (wrong user input)
• Error messages. (how and where)
• Ethical considerations
• Extensibility (adding features, upgrades)
• Failure management
• Failure tolerance (defect in system execution)
• Install-ability (easy to install?)
• Internationalization (e.g., different countries, languages)
• Interoperability (properly interfaced with and working together with something else)
• Language (style of writing, target group)
• Learnability (easy to learn)
• Legal (licensing issues, patents-infringement-avoidability)
• Logging
• Logistics
• Maintainability
• Memorability (easy to remember how to do thing in the system)
• Mobility (Can it be used on the move)
• Modifiability
• Multi user scenarios (collaboration, access to the same objects at the same time etc).
• Network topology
• Open source
• Operational , manual procedures
• Operability (possible to perform tasks in accordance with operations manual?)
• Packaging
• Performance / response time (performance engineering)
• Personalization (personal user experience)
• Performance (Jitter, Response time, Latency)
• Personell (and resources)
• Platform compatibility
• Portability
• Precision of data
• Price
• Privacy (GDPR)
• Provisions
• Protocols
• Quality (faults delivered or fixed)
• Reuse-ability
• Recovery (e.g. mean time to recovery - MTTR)
• Reliability (e.g. mean time between failures - MTBF)
• Reporting
• Resilience
• Resource constraints (processor speed, memory, disk space, network bandwidth)
• Response time
• Reliability (operates without failure under specified use)
• Robustness (also functions under abnormal conditions)
• Roles (Who can add, edit, delete, view)
• Safety (preventing / dealing with accidental harm)
• Scalability (horizontal, vertical)
• Schedule-ability
• Scope
• Security (tolerance against malicious harm)
• Source code
• Stability
• Subset-ability (easy to make different functionality subsets)
• Support (end user support)
• Survivability (essential services continue in spite of accidental or malicious harm)
• Style
• Templates
• Testability
• Throughput
• Traceability
• Training
• Transportability (possible to move system)
• Unambiguity
• Usability (ease of use)
• Usefulness (useful to use)
• User experience (system perceived as fun, satisfying, enjoyable, entertaining, helpful, motivating, aesthetically pleasing, emotionally fulfilling, rewarding and supportive of creativity etc)
• Validation (of user inputs)
• Verifiability
• Variability (degree to which different variants exist)
• Withdraw-ability (can a specific version be withdrawn and replaced with a previous, version)
• Workflow
• Workload (low perceived workload by user)

References

http://en.wikipedia.org/wiki/Non-functional_requirement

http://www.idi.ntnu.no/grupper/su/fordypningsprosjekt-2005/eide-fordyp05.pdf

Scrum taken to the extreme, doing design of features in the same sprint as they are to be developed

On one of the projects I participated on last year I had the opportunity to work on a large project (more than 15 participants, several locations and several interfacing systems). It was decided to do design of products/features in the same sprint/iteration as it was to be developed. This is not the ideal situation as several others have experienced before me [1],[2],[3],[4],[5] and as described by best practices [6],[7],[8],[9],[10].

The background for this decision was that the clients company profile rebranding project was not finished so the designers did not have what was needed to do the complete design job beforehand. Therefore the design team could not really start their job before the developers. Because of this it was decided to have sort of sub iterations within each sprint. For each sprint a set of products were planned and then designers started designing products as on an assembly line. As each product was designed it was delivered to the developers at once to be implemented.

About the project and team composition

Both developers and designers were quite flexible and competent. The development team had some experience with design and the design team had technical knowledge and could even do frontend programming. The project aim was to develop a new Intranet on a new platform. Re-branding was a key goal. It must be mentioned that the developers outnumbered the designers considerably. There was a fixed deadline and the total project length was about 8 months.

This is what happened

The project started out in good spirit. Everyone was confident and happy but after a while things started to go less smooth. As with all projects with a certain level of complexity there is not just one single thing slowing down production. I'll try to concentrate on the issue of in-sprint design and development (design and development of a product in one sprint).

Planning

Since design was not complete at the start of each sprint, developers could not estimate the job since they did not know what exactly they were to develop. This had the affect that the project lead did not have the slightest idea how much would be completed after each sprint.

Doing design in the same sprint as it is to be developed also made the progress flow extremely unpredictable. The time required for design is often hard to estimate and designers often meet unexpected problems in their design as we developers do in implementation. This means, without any lag between design and development, the risk of encountering blocking impediments are doubled.

Specification and Handover

As designers were to handover several smaller designs it was easy for them to to make readjustments to the design specs as these mini, continuous handovers became less formal. This resulted in frustration on the developers who had already started developing the design.

Because there were no big formal handover and the designers were already overworked it was easy for designers to get in to the trap of handing over items that did not follow the required documentation guidelines. Items got sent by e-mail and people forgot to upload it on the correct place and adding the agreed descriptions etc. This again led to difficulties in tracking changes and finding the specs.

Since the designers worked more or less in parallel with development there was always some spec lacking. Developers constantly needed to ask the designers for specs and after some time all the designer was doing was feeding developers with design. This situation where the designer was pressured also had the effect that designers did not always have time to do good overall design making the entire design harmonize. 

In other cases the designer were overrun by developers and developers started dictating the design because the designer was overloaded with work.

Another side affect was that designers had less time to prepare and get a strong acceptance on the next design. On a few occasions design did not go through a quality assurance loop with the customer resulting in bad features that had to be redesigned later. As each user story was a minor handover stakeholders could not really be involved in the acceptance of the design as it would then slow down the project considerable if several parties were to be included for each of these small sub deliveries. Instead the designers controlled the process and sought out who to contact to get the necessary feedback. This had the effect that some persons did not get the chance to see the design and give feedback before it was delivered to the developers. In some cases this proved disastrous as some important stakeholders had important information that did reached neither the design nor the development team. Some participants felt overlooked as they did not get the chance to participate in the design work or not even being able to comment on the design proposals.

Communication and noise

Often specs were not very detailed and in many cases completely absent. Less documentation is part of the agile manifesto but since we had developers at several locations this became a problem. Less documentation means more face to face communication and communication with instant messaging, phone, e-mail, but in large projects, participants tend to have a lot of meetings and thus not being available for communication about specs. Developers often found themselves sitting and waiting for people to come back from meetings when having questions about some design that may have had an incomplete spec. In other cases they just started on some other product which in turn led to a chaotic work environment when the developer ended up with working on 4 user stories at the same time. Not being able to complete a module/product adds noise in the project as the project needs to bring this product up in each scrum meeting and you have to tell once again why the product is not complete. Several products also seemed half finished since there were no complete specs and relevant persons were not available at the same time to clear up design issues.

The incomplete or lacking specs had the effect that everyone on the project needed to communicate a lot more. Time was wasted as messages had to be repeated. As much of the work surrounding specs or the specs themselves was replaced by face to face communication people outside the core group had to ask for information, this resulted in multiple and overlapping communications.

The IA/GD/UX team will always have some questions for the developers but since both design and development is done continuously and in parallel there will be a continuous flow of inquiries for the developers. Instead of having planned design workshops were designers could get feedback from developers and others, we were doing development and design in a continuous and overlapping fashion. This is not optimal for a typical developer. Developers will always be prompt and ready to delve in to planning, problem solving and answering questions in the planning phase of the sprint. But, once developers get down into the nitty gritty programming, many developers will have their head wrapped around difficult tech problems and are not in a mindset to constantly respond to small design issues put forth by designers. Many programmers are also competitive. Non-programming related distractions in the middle of the day are not always what the developer is most keen on. This had the effect that some design problems were not well thought through because the solution was based on feedback from a developer who had other more important things to think about.

Experienced developers want to know what features should be developed next so they can chunk together related work including fixing bugs on related stuff. But as they now live in this day by day design hand over they did not know what features would come the next day and ended up scratching their head trying to figure out this himself or trying to find this out from the IA or designer. The designer works on other things so there is noise. Not being able to chunk related work led to less efficiency.

Workflow, predictability and work conditions

In the early sprints developers tended to have little work in the start of the sprints as they were waiting for design. In the end of the sprint developers were often unmotivated from taking on new design since it was something completely new that they might not have seen before. Completely new design are more intimidating than a design that has been slowly setting in the developers head during the sprint and where the developer has gotten the time to figure out how to best solve the task.

As designers were fully entangled in pushing design they had little time to look over the end result and developers had to go ask designers to test if the implementation of the design was ok.

Developers did not know when they would get a design and what it would look like. This led to unpredictability and unsystematic work making the flow less streamlined and more ad-hoc.

It all became very unstructured. Some people, often the creative ones thrive in chaotic environments but for many developers, often systematic engineers, it became very messy.

For new developers, especially the juniors, coming on to the project late it must have been a nightmare not having the knowledge that had been communicated only by mouth and feeling that they add even more noise in the project. For some of the seniors on the project it did result in a lot of extra guidance and support on these new participants. Incomplete specs were even more problematic for new project participants because they did not have the big picture. So again more noise.

Technical forward thinking, architecting and code quality

Since we did not know what design would come later we could not estimate development time sufficiently, therefore the tech lead did not know if we had time available to do maintenance  refactoring and other things that would benefit the project in the long run. All he could do was either concentrate on getting things up and running or taking the chance on doing refactoring and risking not being able to complete later features.

In general there was a lot of unsystematic work and unpredictability making it harder for the tech lead to plan in advance and see where to do refactoring etc. Unit testing was out as everything was changing day by day. Setting up unit tests takes time and is a waste of time if the requirements change and the code is likely to be totally rewritten the next week.

As specs seemed incomplete or being suddenly changed developers often became demotivated knowing that what they developed would probably have to be rewritten. This resulted in lower productivity, poor code quality and features that were only partially completed.

Since designers were overworked they where not always available to do these kind of in front of the screen 2 minute designs that often are needed for some small thing that was overlooked in the design phase. In this case the developer just design the thing him self.

Testing

Some developers felt stressed out as some design was delivered just few days before the end of the sprint. Most developers want to deliver as much as possible so this results in a situation where the developer wants to produce new features but gets overworked and forgets the importance of testing or preparing for testing of what has already been implemented.

Because of poor specs, test scripts were poor and this resulted in test results that were not realistic and testers did not know what had been completely developed. Some products were set as ready for test before they should have.

Because specs was hard to find specs were in some cases even skipped. Some features were even developed without a developer looking at the specification. In some cases features were developed without a spec as there where no spec available. In many cases this was not a problem as the feature worked out quite well. The designer could then go over afterwards and suggest improvements.

Because design was immediately delivered to the developers when ready it did not get to mature and therefore some design was a bit premature and ended up as features that eventually had to be replaced. If the designers had a week or two to digest and circulate the design it is more likely that the design would be better and that it would lead to a better solution.

Coupling design specs to prototypes to issue/task tracking and to test scripts became difficult. For project participants not sitting next to the designer it was hard to know what design was finished.

Incomplete specs led to vague definitions of done criteria and test scripts were hard to write.

Summary of problems with doing design in the same sprint as it is to be developed

• Difficulties planning and estimating work
• More unpredictability and increased risk
• Poor documentation and traceablity and findability of documents
• Often change in specifications
• Design not always harmonizing
• Redesign and reimplementation because first version was not good enough
• Relevant persons are not included in the design phase and felt overlooked
• Noise, duplicate messages and repeated tasks
• More waiting for clarifications
• More difficult for new and remote participants
• Design and development cycle partly broke down
• Unit testing got more difficult and code quality got worse
• Lower productivity
• More half finished features
• Difficulties in writing and organizing tests
• Poor tests and test results
• More distractions and chaos
• Less happy team members

Discussion

Again, it is difficult to exactly know what factors led to the problems listed above. There were several other decisions that are likely to have contributed to this situation. Having analysed the situation and thinking back on other projects I do believe the list of problems are representative to the issue of doing design in the same iteration as it is to be developed.

Being a developer on this project I am certainly not without some bias, so I'm inclined to say something positive about the process. But hey, as I'm sitting here writing this blog post I can't really come up with any benefits of setting up the process this way. Doing design in iteration i+0 might work perfectly well for small co-located teams but for a project with scaling factors [11] in a large corporation having strict requirements on compliance, traceability etc with a large distributed team this just don't work very well. Agile is all about good communications [12], but our situation got to the point of communications overload and the development process almost broke down. 

What can you learn from this?

Do not do design in the same sprint as it is to be developed. The design team should always be at least one sprint ahead of the developers.

The optimal solution would be for the designers to have a complete initial design ready before the bulk of developers start development. During this design phase selected developers, stakeholders and customer representatives etc help form the initial design. During development designers are tightly integrated into the group but are mainly working on evolving the design based on user feedback and on unexpected technical limitations etc. They would also focus on specifying details or things that have been overlooked.

How to avoid this situation

Plan and make sure managers, project lead, steering committee, product owner, decisions makers or other relevant persons are aware that designers should start ahead of developers.

What to do if you end up in this bad situation

1. Have the developers implementing core features without any UI design while the designers are working on the initial design. Get the solution up and running. After all this is what Agile is all about; making sure you have something working and then iterating to improve it.
2. For projects with scaling factors [11], formal design specifications are more important than on smaller co-located projects. A person can be assigned as responsible for documentation making sure specs are in order. If designers don't have time to do deliver good specifications then someone else should be in charge of writing up and formatting the specs.
3. Make sure the project is staffed up with a enough designers. This will obviously depend on the type of project and aesthetic requirements. If there are 8 developers you might need 4 designers, such as an Information architect, an art director, an user experience designer and a graphical designer.
4. Using teams of designers and developers that have previously worked together on projects with the same technologies. This will minimize the friction between designers and developers and reduce uncertainties.
5. Designer(s) must be tightly integrated and co-located with the project.

References

[1] CHI 2009 ~ Case Studies ~ Experience with Software & System Development and Evaluation

[2] Bringing User Centered Design to the Agile Environment

[3] UX Matters - Clash of the Titans: Agile and UCD

[4] IXDA - Discussion Archives - Interaction Design in an Agile Environment

[5] IXDA - Discussion Archives - UCD and Agile Programming - models of involvement

[6] Prior to Sprint Zero: A Note on Jakob Nielsen’s “Agile User Experience Projects”

[7] Agile + UX: (un)Synchronizing UX and development

[8] IBM Design - An Agile approach to User Experience and Design

[9] MSDN - Magazine. Usability in Practice, Agile Ux Development

[10] InfoQ - Agile User Interface Development

[11] IBM - Agility@Scale: Strategies for Scaling Agile Software Development
[12] Agile Principles and Values, by Jeff Sutherland