Blog

Hello again.

It's been a pretty long time and things have moved along and like every gap in between blog posts I'm more experienced, I'm older and (allegedly) wiser.

There have been things to be disappointed about, namely exam results.  However since my last Blog Post I've had some time to work through a few projects and learn some key lessons.

Estimate Engine (Completus)

Before I'd started this project, I was aware of some terms that get thrown around with estimation.  Mainly through being told my Estimation was awful and these were terms to consider.  In terms of self-diagnosis, this project came at a good time.  Mainly because my initial estimates were incredibly far off the mark and that the software I was creating would show me just how far off I was, in a multitude of ways.

In terms of data Estimate Engine keeps track of a few things and the database it's built upon reflects this.
From the bottom:

• Estimates with a date, a minimum time estimated, an expected time, a maximum time and the person who gave it.
• Tasks, with people assigned to them and the estimates given for that task.
• Projects made up of Tasks
• Clients made up of Projects
• People being assigned to Tasks who also give Estimates.

Here's a chart I made as I did my planning.

I'll mention my initial mistake in a little bit.

This was the second time I was left to my own devices to make a database and build something off of it (in an official capacity) and I'm pleased to say it's not awful.
Go me.

Importantly I started this project the right way, as opposed to my previous attempt at making a Web Application in full.  Building out from the back, always aware what I would need the data for, how it would be organised and displayed and how it would have to be manipulated on the front end.  In my last project like this I did it completely wrong, I designed a website first, then decided how I would need the data to appear, then I designed the database.

I feel like the number of times my past mistakes make me cringe is inversely proportional to the amount of mistakes I make at present, so I'll put my past stupidity in the "Silver Lining" box.

Moving on from the Database into MVC, again, after my last attempt at this sort of application I looked at some of ways not to make those kinds of errors again and MVC was the answer.  As such there are plenty of pages throughout Estimate Engine that resemble default MVC website structure very closely.

Previously I had been trying to "reinvent the wheel" and make too much of my own code to do everything, where things aren't broken, they don't need fixing.  In terms of allowing the user to Create, Update and Delete data the default MVC setup is perfectly quick and easy, what changes there are on those pages are the result of giving the end user more information what effect the action will have, for example:  When deleting a task, it would list the number of estimates you were about to delete and what people were going to be affected.

The point of Estimate Engine was to show how estimates would evolve over time, so that the we at Antelle could see where we were under or over estimating projects and to what degree.  There were a number of ways to show this information and most involved some maths that initially was over my head a little.

To talk about the two most interesting ones features of Estimate Engine, we have first the Cone of Uncertainty.  The Cone of Uncertainty (CoU) shows the evolution of estimates along the timeline of a project, to make a long explanation shorter, the perfect CoU shows that initial estimates will show a minimum estimate that is about a quarter of the actual time taken on a project and a maximum estimate about four times the time actually taken.

As the project progresses you can become more accurate, in a perfect world the minimum and maximum estimates will trend towards one another, getting closer and closer until the project is actually completed.

In the Antelle world, the Cone of Uncertainty generated by Estimate Engine tends to resemble a rollercoaster as requirements are added and taken away over the course of a project.

 The other interesting feature was Estimate Confidence.  A percentage confidence in how long a project would be completed given the estimates that already existed.  Again, the gist of it would be that the more confident you would want to be in an estimate, the more the estimate would drift from the "middle point" of your estimate towards the maximum estimate that was given.

For Example, given an Estimate of:

• Minimum Time: 1 Hour
• Expected Time: 2 Hours 30 Minutes
• Maximum Time: 3 Hours 15 Minutes

The 99% confidence figure for this estimate would be: 3 Hours 28 Minutes
Whereas the 1% confidence figure would be: 1 Hour 15 Minutes

Confidence roughly relates to the likelihood that a project would be completed within that time.

The Cone of Uncertainty was created by tracking the latest estimate per task on every date that an estimate was given, then charting the total amount that was estimated on that date, meaning that out of a potentially large number of estimates to manually track, there was a visual "at-a-glance" representation of where the project was, whether that be close to completion or if there was still a lot of factors up in the air.

Confidence is useful for handing estimates to clients, it is better to give an estimate that you can be reasonably sure about as soon as possible.

While a great many things went right with Estimate Engine, there was an area that was sorely lacking.

User Interface

User Interface, UI, Front End.

So about that mistake I mentioned.

Whatever you want to call it, the reality is that no amount of good code and solid framework for your application can make someone want to use it.  Close to the point I was willing to hold up Estimate Engine and be happy with it I was made aware that using the application was unintuitive, confusing and hard to efficiently navigate.  As per my data model, the top level was the Client, so I laid it out with the Client at the top and you navigated down from there.

There wasn't a navigation bar, no search ability.  Tellingly and incredibly obvious with any amount of hindsight is that in a program to track Estimates in Projects and see the Accuracy of the People giving those Estimates, there wasn't an efficient way to do either.  So, I reworked, I made sure that projects were easy to navigate from the homepage, I included a search for quickly finding what you wanted and added in a breadcrumb style navigation bar.  Once these were in place, the pages remained the same, but now the User could go where they wanted and not where I thought they should go to get things done.

It's an important lesson and it's dominated my front-end design thinking ever since.  It's of paramount importance.  Giving users more and easier control is more important than any other fancy aspect of your application.  Estimate Engine is twice as appealing to use as it was before I revamped the UI and that's no coincidence.

Razor

Where oh where would I be without it?

My first introduction to razor was building a navigation bar for an Umbraco website.  Now it seems to be at the center of any complex web development I do, the fine degree of control it gives over displaying data on a page in any way you would like is astounding, Estimate Engine was built on tables and Razor can do them like nothing else.  To manually sit there and write Javascript to make a table based on data received from a request seems like an age ago.  Delivering HTML tailored to the type of data you pass through to it is my favourite convenience in programming.

Project Management

Maybe they're not the right words for what I'm about to talk about but anyway.

Over the past few months I've been given a few more things that are "mine", I make it all from the ground up, I get the brief and I "go".

Before I got a handle on it, this mostly led to poor design, coding outside of good practices and all in all, a terrible end product.

Most recently that's improved with work on Estimate Engine and my latest Umbraco website.  I'd like to think now that I'm better at thinking things through all the way from back to front.  As I said about Estimate Engine, it means starting right and going on like that, making better choices, being aware of easier choices like not reinventing the wheel just because I can.

I'm by no means going to toot my own horn too much.  I'm slower than I'd like, my inside and out knowledge of C# is nowhere near where it needs to be.
I am going to toot it a little though.

I think that it's a positive sign when I'm solving problems with experience rather than running at high pace straight to Stack Overflow.  I'm making many, many fewer coding mistakes and things are more streamlined.

Most importantly, I'm now writing code that is working perfectly first time far more often than a few months ago.  That makes me happier than most other things if I'm honest.

 

 

My Blog Post writing skills are a little rusty, but I'm optimistic and really enjoying where I am right now, I feel like things are now really sticking and starting to improve in a meaningful way, but improvement is the name of the game and I still need to get better.

Until the next time,

Ben