Apps optimize

My application lifecycle in Agile Platform

Developer Justin James shares some of the lessons he's learned about doing consulting work with OutSystems Agile Platform.

One thing that attracted me to the OutSystems Agile Platform was the development lifecycle; the product is designed from the ground up to encourage Agile practices. You don't have to use something Agile to work with the system, but it enables Agile methodology very well. Here's a walk-through of the lifecycle of a typical project with Agile Platform that works great for me. (Note: Others in the ecosystem may do things differently.)

The iterations

An iteration is a defined block of time to perform development work as a complete unit. On my projects, I find an iteration that is based on 10 hours of estimated development work is just right. At the beginning of an iteration, I sit down with the client, review their list of desired changes, and provide a rough time estimate for each item; this includes the testing/fix time (I guesstimate that for every eight hours of development, I need two hours of testing and fixing). The client selects what will fit into 10 hours based upon their needs and priorities, and then I get to work. When I am done, I demo the functionality back to them. If they are happy, we deploy it to their Staging server for their testing. Any bug fixes ("doesn't work as spec'ed") I do as part of the iteration. Any changes ("spec doesn't match needs") goes into the request bucket. In general, iterations have a turnaround time of one week.

You might think 10-hour iterations are rather short, right? Well, not really. First and foremost, I do this work on a freelance basis; I do not want a situation where if I go over the 10 hours that I'm burning the candle at both ends or being an absentee husband/father. A 10% overage on a 10-hour iteration is one hour; it's four hours for a 40 hour iteration! Secondly, I've found that the Agile Platform is so efficient for me, that I can do in 10 hours what most full time developers need a full work week to accomplish in ASP.NET or a similar technology. As a result, my bill comes in much lower than a typical developer's for the same workload, even though I charge a tidy sum per iteration. Thirdly, it's been my experience that estimation mistakes tend to snowball very easily. A 10-hour iteration constrains that issue. In addition, 10 hours of development work is small enough that the work can be quickly and easily spec'ed out, without much need for changes in the middle of development. Finally, with the number of features done in one of my iterations, the customer wants a chance to review things before choosing the next set of features to implement or changes to make.

Initial project discussion

One thing I refuse to do is provide an up-front estimate. At best, if I think the project can be done in three or fewer iterations, I will tell the client. Some customers do not like this, because they want to see a "guaranteed" price and timeline. I remind them about the other "guaranteed" projects they had with other vendors that quickly went over time and budget, and gently explain that in the world of development, nothing can be guaranteed. When they see that my iteration methodology keeps their costs constrained and doesn't give me free reign to ring up a huge bill, or create a situation where I need to "descope and declare victory" to make a profit, they are usually sold. For a customer who cannot be convinced of this, I do not play ball. I simply do not have the time or the energy to spend on contracts that I know will be hard to make a profit on.

Beyond that, I use this period to get a good idea of the client's up-front needs, particularly to understand their future roadmap ideas to ensure that the application architecture makes it realistic.

Deployment

As alluded to, I like to demo the work on my servers first. I have a server that my customers can access. I recommend to my customers that they have two servers -- one for Production and one for Staging -- but it's not the end of the world if they cannot afford that. Nicely enough, high-end Agile Platform licenses include a not-for-production-use license, and I believe that the cloud offering from OutSystems does as well. Otherwise, the client is free to experiment with the project on my server.

Once the client is happy with the results, I deploy to their systems. Agile Platform makes the deployment really easy. Typically, I just need to log in to the Web-based administration, upload the single OML or Solution file (depending upon how I am working), and after it uploads and compiles it is ready to go. All of the database schema changes are handled automatically. I should use the "Solution" approach because it lets me cut a single, unified file with all of the extensions in it, but since I rarely change extensions, I tend not to in order to reduce file size.

Sometimes a new version will require some data to be inserted into the database or otherwise manipulated. For example, in one project, each customer account has a list of statuses that they can use for workorders. The list can be customized, so when the account is created, it gets copied from a master list. Sometimes I need to inject a new value into that list for a new feature. Instead of needing direct database access, I create an Action that handles the data manipulation, and then tie it to a Timer with no defined schedule. After deployment, I manually trigger the Timer to run from the Web-based Service Center, and once it has run, I disable the Timer. I make sure that future versions remove the Action and Timer completely. As a result, the only times I need direct access to the database are low level data checking or fixing.

Pricing

To make life easy for all involved, I charge a flat rate per iteration. It's a fair rate for the customer, especially considering that any bug fixes are handled for free as part of the iteration. If the iteration goes significantly over time, that's my fault for estimating poorly and it's a good lesson to me. If I'm way under, I offer a "low price guarantee": once the customer signs off on the work and is ready for invoicing, I charge them an hourly rate if the true time spent on the iteration (from top-to-bottom, including planning, review, deployment, fixes, etc.) is under seven hours. This lets the customer know that I am not chiseling them, and provides me with great incentive to plan properly.

Results

Since I started doing consulting work with Agile Platform in early 2011, I have learned a lot of lessons. I had one project become much more work than I intended because the scope of work for the initial iteration had too many open questions at the beginning. I did not ask enough detailed questions up front to realize that the proposed algorithm had a lot of logical inconsistencies, and it ended up getting implemented and re-implemented a number of times. That is a classic programming error that I hope I do not repeat. But for the most part, the short iterations plus flat-rate pricing have done a great job at insulating all parties from the hazards that per-hour and fixed rate contracts typically have.

J.Ja

About

Justin James is the Lead Architect for Conigent.

7 comments
Sterling chip Camden
Sterling chip Camden

... it only does web apps with a .NET or Java back-end? That kind puts the "age" in "agile," doesn't it?

Justin James
Justin James

That's right, but believe me, the tool is slick. Customers can't believe my quotes in terms of time and budget promise (and delivered on) for feature set. J.Ja

Justin James
Justin James

I know exactly what you mean. I grew up in this industry, I was hearing "4GL" and "code free" or "plain English syntax" since I remember and I know it was going on long before that, and every time the solutions that were delivered were just awful. I was very skeptical too when I first stumbled across it. For the problem domain that it addresses (Web applications, primarily data driven, where you do not mind giving up control of the SQL and HTML and most JavaScript, while still having 100% control over CSS and being able to add on JavaScript as needed), it is absolutely unbeatable. You can actually write the SQL if you really want to, but I really don't want to... I've found a couple of situations where I wasn't happy with how I had to do things, or how things turned out, but the huge improvements in things like version control, deployment, and especially code maintenance blow those minor issues away in the long run. Also, the company itself is unbeatable in terms of their support staff and willingness to listen to the users. They have a system to publicly collect feedback and let folks vote on what they want, it's pretty cool to see a release where a number of features are tied directly back to items that I personally submitted. So for me and my needs (very important qualifier there!), I've found that it is the only "code free" solution that not only "works" but "excels". Going to something like RoR would feel like trading a Ferrari for a Camaro, and going to ASP.NET would be like going from that Ferarri to a Pinto. Every time I have to touch ASP.NET in my day job, I feel like poking my eyes out with a bamboo skewer. J.Ja

Sterling chip Camden
Sterling chip Camden

Code-free solutions have a long and unsuccessful history in our industry. I'll have to set aside some time to look at this platform.

Justin James
Justin James

There's really no need to. You never look at the code generated by it, nor do you ever touch it. Since you can write extensions in Java or C#, I would imagine that runing JRuby, Jython, IronRuby, IronPython, etc. is possible. But I've found that I do very, very little in extensions. So for me, the thing could be building on COBOL, APL, or bash shell scripts and it would all be the same as far as I'm concerned. :) J.Ja