What is Oslo all about? According to Microsoft's Burley Kawasaki at Architect Insight, Oslo is a new way to build connected applications where services are extended from client to cloud and models become the mainstream part of development. Oslo is not a product but a way of working. http://www.microsoft.com/soa/products/oslo.aspx.
Other things of interest from Architect Insight include the ConfigWeb sample (from Stock Trader) for configuring enterprise web applications (http://msdn.microsoft.com/en-us/netframework/bb499684.aspx). The Internet Service bus and biztalk services (http://biztalk.net/Default.aspx).
Here is part 2 of my MVC/Windows workflow example. Part 1 created the basic MVC application and had a basic model, part 2 adds the work flow element to the model. [PDF] [source]
Scrum is a process to help with the day to day running of projects. From my experience of running projects using scrum I have written an overview document. This is probably not pure scrum but it works and has practical advise. The overview is written from the team leaders perspective and may be useful to new team leaders or existing team leaders who are new to scrum.
overview - Scrum overview (pdf).
Developing software is complex but breaking the problem down into smaller tasks makes the job easier. It is OK if you are the person who defines the work, splits it down and then completes it yourself as you fully understand what the problem is and when the problem is solved. This is not normally the way it works in the real world. Here the problem is defined by the customer; there is generally someone or a layer or people defining what needs to be done to solve the problem and then a group of developers who are actually implementing the solution. Once the problem and its solution are split between different people the concept of complete starts to become an issue. There are three points of view of completed: Developers’ perspective, Team Leaders’ perspective, Customers’ perspective.
The customers perspective of completed is when the customer gets what they want. This is not necessarily what is in the requirements. One of the biggest problems with requirements is that the person or people who normally write them understand what they want and often assume that something will be like what they want without actually specifying what it is they actually want. These are hidden or implicit requirements.
The team leaders’ perspective of completeness is when the developers have told the team leader that the task is completed and the software has been built, deployed and is in a fit state to test or demonstrate.
The developers’ perspective dictates that something is complete when the item of work given to the developer is completed as close to the specified design as possible. If you are lucky the developer has let the team leader know which parts of the design have not been implemented for whatever reason.
These three perspectives often are not compatible with each other which lead to disappointment with the customer as things do not appear to be going to plan even though the developers and team leaders think things are going well. If you are not careful this could lead to a de-motivated workforce and an even more disappointed customer.
One of the secrets of a successful development is to align the three perspectives of completion. This generally lies with the team leaders or project managers. This layer of the development process, interfaces with both the customers and the developers and it is their actions that ultimately determine how successful the project is. For simplicity we shall assume that the team leader is handling this issue. It could easily be anyone of the senior members of the development team: the consultant, designer, project manager, team leader etc. It is the team leaders’ responsibility to fully understand what is actually expected to be delivered to the customer. If the team leader does not fully understand what is required then how can anyone expect to get what they want? The team leader must rely on fact and not hearsay or rumours. The team leader must understand the requirements and try to work out what the implicit requirements are and handle the delivery expectations of the customer. If there are features that the customer seems to be talking about that are not explicitly specified in the requirements then the team leader needs to get to grips with what the customer is expecting to be delivered. This will often contradict with what the development team has been contracted to do. This may require that the project manager needs to ensure that the scope of the project is managed and that additional work is charged accordingly (assuming that the customer and developers work for different organisations). It is the team leaders’ responsibility to make sure that the customer is aware of what is being delivered at each stage.
Once the team leader has aligned the customers’ expectations with the requirements the development team can now work to complete the tasks. To make sure that the team understands what they are expected to deliver the team leader must specify the minimum criteria for completeness. This is effectively a set of tasks which explicitly defines what needs to be done. This will include testing, preparing for a demo (including what features are required to demo) and building and deploying. The goal of the team needs to be specified so that all the development team understands what is expected from them. The team needs to be made responsible for delivering the demonstration and the whole team needs to be involved with its preparation. This means that whilst the demonstration is being prepared and the software is being built and deployed, any problems are resolved as soon as possible by the development team. In addition to this any short fall in specification needs to be identified as early as possible so that the customer can be notified and/or the problem resolved before the item is delivered as complete. It is the team leaders’ responsibility to ensure that all this happens, if the delivery is not successful then is it not acceptable for the team leader to blame any member of the team. They are ultimately responsible for the successful delivery.
Aligning the perspective of completeness of the customer, team leader and developer is one of the key to successful software developments. The team leader is the catalyst for this alignment and needs to be able to communicate effectively with the customer and the developer; to understand what is required and to communicate this to the development team.
Having read the article in MSDN magazine about the Microsoft MVC, I decided to have a go myself, I also though it would be a good idea to try to combine this with Windows Workflow and see if I can control the order of pages based upon the state of a workflow state machine. In Part 1 I build the MVC application with a simple model that determines the page order of a wizard type interface. Part 2, which is coming as soon as I manage to write it up and tidy up my demo :), adds the work flow element to the model. [download PDF source]
In this ever growing connected world of computer automation the user interface is becoming more and more critical to the success of a business and the success of a business computer system. The world is moving towards a service-based architecture with the web being the conduit to link all these services together. Ease of deployment is a factor in the move to web based user interfaces for business applications and this move poses challenges for software developers around the globe.
Whilst the underlying architectures are changing the basic premise for a user interface is still the same: To make the business functionality easy and obvious to use. Vast quantities of Time and money are spent developing the back end systems and relatively little is consumed designing the user interface. Most user interfaces that are developed are functional in behaviour, but they are not always usable or appear “Clunky”. The developer is not to blame for this, as the whole development process does not necessarily make the user interface as important as the back end systems and architecture. No one spends real time analysing the way the data should be presented and the way the screens interact with the user; different teams of developers develop the screens so there is not real consistency to the designs and no time is spent assessing the needs of the user when designing the user interface. Quite often the user interface is too complex and is trying to accommodate all users all of the time and often makes the often-simple task hard to use.
One client termed the phrase “Clicks Cost Money”. In an organisation where the throughput of customers is the main factor in profitability the business needs to get the customer though the system as quick as possible so the more clicks the user has to do with the computer system the longer this process takes and therefore the less money that is received by the company.
The user interface needs to be consistent through out so that when the user is presented with a screen it behaves the same way in all scenarios. The number of actions required to complete an action needs to be as short as possible. A few years back I was reading an article (I can’t remember where) that stated that each user needs to do a maximum of 3 clicks to complete a task and that it should take no longer than 1 second.
The design of the user interface needs to be brought in to the forefront of the development cycle. When I talk about design, I do not mean the bit where you make it look pretty and have the right colours (i.e. styling), I mean the actual functionality and behaviour of the user interface. Thought needs to be given to this and the developers need to be given a style guide to work with so that each of the screens is consistent using the same styles and controls.
Designing the user interface has a lot to do with the way the business is run. Each screen needs to present enough information for the user to be able to make the right decision, ask the right questions or gather the correct information so that the real business benefit of the system can be achieved. The design documentation needs to spend more time on the behaviour of the user interface and the interactions. We should be concentrating upon making the user interface easy to use and responsive
During development it is not just enough to say that the user interface performs the function it was designed to do to be fault free. It needs to adhere to some common sense values as well. It needs to be responsive, it needs to be easy to use, and it needs to behave, as you would expect it. Getting these ideas across to the developers is difficult. Time needs to be spent designing the user interfaces and documenting them in a way that is easy to understand by the developers. Developers will develop user interfaces that are easy to build not necessarily easy to use, so we need to educate them in what makes a good user interface. We need to put guidelines in place so that the user interface can be evaluated which should include response times for actions. We need to have User interface Design guides to specify common actions to make the user interface consistent and we need to understand the business requirements for the user interface so that the information that is needed most is easy and obvious to get to and that the day to day running of the business is as efficient as possible. After all that is the reason for putting the computer systems in place.
A while ago I was looking for an alternative to System.Diagnostics.Trace and found Log4Net. I know the patterns and practices group have created enterprise logging but I find Log4Net nice and easy to use. I created some documentation and samples on my website at http://www.recneps.co.uk/log4net.aspx.
The BlackMarble.Diagnostics.Logging libraries encapulate both System.Diagnostic.Trace and Log4Net so that we can use a standard way of logging and then configure at runtime one we want to use.