I’ve been working with scrum for a few years now and here’s what I like with this methodology …
Features gets broken up into small pieces
Usually a sprint is 2 weeks long which isn’t a great deal of time to get large features developed and tested. This encourages us to break work up into small pieces which is good for estimation – small bits of work can be more accurately time estimated than larger work. There are more useful benefits to work getting broken up though …
Encourages the MVP
Given that we need to break large features into bits, it makes you really think about which bits should come first? Often it makes sense to deliver the core of the feature first – just the bits that are needed for users to be able to viably use it. With the core of the feature released, it means we have delivered real value to the product much quicker than we would have if we had developed the whole feature before release. We then get real feedback from users on the core feature before we start developing bells and whistles that we think are important.
Going down the wrong path during development can be very costly. Sprints encourage every bit of work to be tested regularly. The sprint review gives the wider business a chance to give input and help developments stay on track.
Regular reprioritisation and planning
The demands on a product change frequently – change requests, bugs are reported, … Only committing to work at start of each sprint gives flexibility to help meet these demands.
In the previous post I gave an overview of what a SPA is. However, why would you want to use a SPA? They certainly aren’t right for every app but I believe they are a good option for many line of business apps. Here’s why …
Web rather than native
There’s more than Windows
Lots of line of business apps target windows desktop. This is because windows has been dominant for many years and technologies like .NET windows forms and WPF have allowed rich windows apps to be built at relatively low cost. The landscape has changed though – you can’t just target windows in many situations and you have to cater for Mac, iOS, Android, … A web app of course is platform independent and can be built to target desktop, tablets and potentially smartphones.
Tooling is getting better
The cost of building a SPA is probably still greater than building a .NET windows forms app – the tooling for windows forms is great! However, the tooling around SPAs is getting better and with so many big companies in the software industry investing in this area, I can see it rapidly continuing to improve.
Free / low cost tooling
The functionality that exists in Chrome dev tools today is already amazing with functionality like memory profiling that I am used to being in a paid for tool. I am used to paying for 3rd party UI components for windows desktop apps but in the web world you can get a lot for free with components like Bootstrap and some parts of KendoUI. UI Automated testing is another great example where there are lots of free options in the web world such as selenium but the tooling in the windows desktop world tends to be expensive.
SPA rather than server driven
So, building a web app is a good option, but why a SPA and why not a traditional server driven web app? It goes back to one of the reasons why so many line of business windows desktop apps have been built over the years – performance is important. Critical line of business windows desktop apps have users constantly using them throughout the day and so the user experience has to be fluid and fast. Users having to wait for a full page refresh to do the next thing wouldn’t be acceptable in many situations. Of course a server driven web app can use ajax to avoid full page refreshes which can work very well but that can lead to code that can be tricky to maintain because things like UI logic are placed sometimes on the server and sometimes on the client. This often happens when the developers are more comfortable with the server technology.
I also think that SPA’s are great for windows desktop developers transitioning to web development because the architectural patterns are similar with the client maintaining the state rather than the server. When I started developing server driven web apps, the difference in where the state was stored was a constant battle for me.
But why weren’t we doing SPAs years ago?