Tag Archives: Mindscape

Keeping your software young

01 Monday Oct 2012

Posted by in On Technology

≈ Leave a comment

Tags

, ,

Every once in a while, I look at the date and wonder how fifteen years have passed since I graduated high school.  Looking back at those four adolescent years, they feel more like four decades.  It is crazy to experience the speed of life.

The software we build wonders the same thing. Has it really been seven years since that website was built?  Wasn’t it just yesterday that Ajax was the thing of the future, and IE 7 was the greatest step forward in Internet history (ok, maybe that was never the case).

Time and Technology stop for no man, and it certainly does not stop for the applications we build. So what can we do to keep them fresh and healthy?  It’s not so different from the additional exercise, better diet, and regular checkups that we do for ourselves. In the case of technology, the key is to keep up on blogs, product releases, and to continue to use the application so you can understand its needs.

Microsoft released .NET 4.5  on August 15, 2012, and I was pleased to have a few minutes to install Visual Studio 2012 with .NET 4.5, and give webTRAIN, our Web Marketing Platform, an upgrade.

webTRAIN was built back in 2007 as a .NET 2.0 website using Visual Studio 2005.  Since that time, we have upgraded it to .NET 3.5 and have been using Visual Studio 2008 to code it.  I really have been looking forward to upgrading to .NET 4.0, but I wanted to wait until we had new servers with IIS 7 installed.

We made the move to a new 4 server network with IIS 7 a few months back. With that, we were finally able to consider moving to .NET 4.  I heard .NET 4.5 was around the bend, so it made sense to wait just a bit longer.

The actual process of moving into Visual Studio 2012 and .NET 4.5 was not as painful as I thought it would be.  We have run into two hiccups so far in our testing.

1) .NET 4.5 handles request validation differently that .NET 3.5 and .NET 4.0.  This came up specifically when trying to pass HTML from a Tiny MCE editor to our model.  We found the answer in this whitepaper. The portion that affected us was “Support for unvalidated requests’”, which I have copied below:

*******************************************************************

To allow this, ASP.NET 4.5 now supports unvalidated access to request data. ASP.NET 4.5 includes a newUnvalidated collection property in the HttpRequest class. This collection provides access to all of the common values of request data, like Form, QueryString, Cookies, and Url.

Using the forum example, to be able to read unvalidated request data, you first need to configure the application to use the new request validation mode:

<httpRuntime requestValidationMode="4.5" ...
/>

You can then use the HttpRequest.Unvalidated property to read the unvalidated form value:

var s = context.Request.Unvalidated.Form["forum_post"];

Security Note: Use unvalidated request data with care! ASP.NET 4.5 added the unvalidated request properties and collections to make it easier for you to access very specific unvalidated request data. However, you must still perform custom validation on the raw request data to ensure that dangerous text is not rendered to users.

*********************************************************************

 

2) After updating our development servers to .NET 4.5, webTRAIN seemed fine and dandy. However, we found that it caused an issue with an MVC app that used automatic build and deploy via Team City on our development server. It built the code against .NET 4.5 assemblies and when we deployed it live, where .NET 4.5 is not yet installed, it ran into an error.

The error was:

Could not load type ‘System.Runtime.CompilerServices.ExtensionAttribute’ from assembly ‘mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’.

We ended up having to retrieve mscorlib from C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0 and building it directly into our application.  It required a manual change to the programs’ XML file to include:

<Reference Include=”mscorlib” />
<Reference Include=”System.Core” />

There’s still lots more testing to do to make sure webTRAIN will play nicely with the new updates, but it’s great to know that we can begin to include Strongly Typed Datasets, Model Binding, HTML 5 snippets, and all the other great .NET 4.5 upgrades into our new features.  webTRAIN is feeling younger already!

Have you had luck upgrading to .NET 4.5?

Aaron Brander is the VP of Technology for MINDSCAPE at Hanon McKendry.

Advertisements

Scheduling is a breeze (Thanks to LiquidPlanner)

24 Friday Aug 2012

Posted by in On Technology

≈ Leave a comment

Tags

, ,

Back in February, we were buried under a mountain of work.  It’s not a bad problem to have, but it sure made for quite the logistical nightmare.  It was not easy to schedule dozens of projects for dozens of team members and still make sure we hit our deadlines.

I wrote about the problem at that time, and a small sliver of hope that had appeared on the horizon. That sliver of hope is called LiquidPlanner.

lp

We have been using LiquidPlanner since February, and it has significantly streamlined our process.  Instead of juggling a calendar for each team member in Google Calendar, we just assign tasks to a team member, put a low and high estimate for how long it should take, and let LiquidPlanner handle scheduling the project.  It’s easy!  The whole team participates in project management now because they can see all of the tasks assigned to them and how it affects the schedule.

Instead of using Basecamp to handle messages, to-dos and file management, LiquidPlanner handles that too. Tasks are central to LiquidPlanner because they drive the schedule. It also allows us to comment on tasks, add messages, and work with clients.

As an added bonus, we can track our time against a task.  So, we’ve eliminated our home grown time tracking system and instead track time directly in LiquidPlanner.

LiquidPlanner is not all rainbows and unicorns.  There are a few things that were nicer in our previous systems, or could use some improvement.

  • The upcoming schedule is not as easy to read as Google Calendar.  They do a great job handling a LOT of data, but it takes time to get used to.
  • Communication is not as nice as it was in Basecamp. The biggest issue is not being able to tie files directly to a comment. 
  • If I assign a restricted member to a task in a project they don’t have access to, they should automatically be added to the project.  Too often we have tasks that people can’t see.
  • Pricing is per user, so it can get pricey.

But in the end, not having to use 3 different systems, and scheduling that is WAY easier makes LiquidPlanner a no-brainer for us.

If you have lots of projects that need to be schedule across many different resources, and you are tired of using MS Project, or cobbling together multiple systems to try and create something useful, give LiquidPlanner a try!

Aaron Brander is the VP of Technology for MINDSCAPE at Hanon McKendry.

Another set of eyes (or Blinded by the Light)

30 Wednesday May 2012

Posted by in On Technology

≈ Leave a comment

Tags

,

sherlock

I just spent the last week banging my head against a wall.  I came away with no physical bruises, though my metaphysical cranium hurts a bit. 

It is not the first time this has happened to me, and I am sure it won’t be the last. And I’m willing to bet that something similar has happened to you, Dear Reader.  

The issue cropped up with our new server environment.  We added a second web server and a load balancer to split traffic between the two machines.  It will be a great environment for both performance and for redundancy.

We ran into a strange issue after running with the load balancer for a few days. It seemed that if we made a change to the website, the two servers got out of sync and started throwing errors. The error mentioned that it was looking for a particular dynamically built assembly file.

The issue happened quite frequently in our old environment, and typically it just took a refresh of the page to get it running perfectly until the next update.  That didn’t work in the new environment. We troubleshooted it for a while, but we finally made the decision to stop load balancing and go back to one server until we can figure out the issue.  As soon as we went back to a single server, the issue cleared up.

To me, that meant it was an issue with having more than one server in the mix.  I began to work with our hosting partner to find a fix while I did a lot of googling for answers. After a week of trying a lot of different things, including making our site work as a precompiled site instead of dynamically compiled, we were no closer to the answer.  I was really confident that precompiling the site would fix it and when it did not work, I was out of ideas.

Enter a second pair of eyes.  Eric Patterson had just come free from a different project, so he helped me look deeper into the issue. Armed with the knowledge of all I had tried in the past week, he took a closer look at the Stack Trace for the error we had.  Stuck deep down in the stack trace, he kept seeing this:
DBauer.Web.UI.WebControls.DynamicControlsPlaceholder.RestoreChildStructure

That is a control that we use to put our “Page Parts” onto the site in the correct order. For me, that was not a clue because I knew it was used on every page.  For Eric, who had no such mental constraints, it was a place to start looking.

He quickly found this article.  It seemed to fit perfectly:
1) Error only in a web farm (which is what we have after introducing the second server) 2) Error with finding the temporary Assembly name
3) Using the DBauer Dynamic Controls Placeholder.

That article has a pretty easy fix to the issue that will cause the Dynamic Controls Placeholder to use a relative path to the User Control and not a fixed path.  If you need the source code, it can be found here.  I made the change to the source code, compiled it, and added it to our website.

The error disappeared!

There’s something to be said for walking through a problem and eliminating possibilities. That needs to be done.  But when you find the frequency and power of your head banging into that wall increasing, go grab someone else to help.  Their fresh perspective can often find you the answer quickly.

Java, JavaScript and jQuery (Or What’s With All the J’s?)

13 Friday Apr 2012

Posted by in On Technology

≈ Leave a comment

Tags

, ,

Technology is full of confusing terms, and building websites is no different. As a developer or as a person in need of a website, you will no doubt encounter a number of acronyms and words that you either don’t understand, don’t want to understand, or that just plain make you want to cry a little bit out of sheer frustration.

DNS? PHP? .NET? IIS? Apache? Joomla? Drupal? CMS? IE? FF?

The list grows longer and your attention span grows shorter. I’ll not bore you with all of the acronyms now, I’ll just save that for another post. Instead, I want to shed a small ray of sunshine upon a dark corner of confusion.

What’s the difference between Java, JavaScript and jQuery?

Java

Let’s start with what Java is not. Java is not coffee; you won’t find it at Starbucks.

Java is not a populous island nation in the Indian Ocean; at least, not the Java we are talking about.

Java is a programming language developed in 1995 for Sun Microsystems. Its main purpose is to be able to run on all different types of operating systems. In other words, a program written in Java can run on a Microsoft computer and an Apple computer. All you need is to download the Java run-time to your computer and you can run any Java applications.

Java can be used on the Web, but I haven’t seen an example of a site using Java in a long time. If someone is telling you they’ll build your website using Java, they probably mean JavaScript.

JavaScript

JavaScript is not Java, just like tea is not coffee and Bermuda is not the same as Java the nation. Beyond some superficial similarities in syntax (the words and symbols used to write the code), Java and JavaScript are quite different.

JavaScript is built to run on the Web. How it executes and how well it performs is dependent on the type of browser you are using (Check out this website to help you determine: What is a browser?).

JavaScript was decried, denigrated and dismissed by many programmers for years, including myself. The relatively recent rise of “fancy” websites that update quickly without reloading a page (Ajax or asynchronous JavaScript execution) has brought JavaScript into prominence, and has even made an old hater like me at least acknowledge its importance.

If a salesperson is talking to you about using JavaScript to build something on your website, they are probably talking about implementing some sort of “fancy” interface feature to make the site more appealing to your visitors.

jQuery

Finally, we come to jQuery. jQuery has nothing to do with questions. In fact, it answers a lot more questions than it raises. jQuery is a library of functions that uses JavaScript. It is like using the phone instead of sending a telegram. It is like sending a text instead of using the phone. It is like using GPS navigation instead of an old, paper map.

jQuery is what made it palatable and fun to start using JavaScript again. It is the most popular JavaScript library in use today, and if you are building a site you should be using it. If you are having a site built, when the sales person talks about JavaScript, it is almost certain that the developer will be utilizing jQuery to make it happen.

So there you have it. Java, JavaScript, and jQuery, now clear as mud for you!

What is a Technical Design (Or Why You Need a Blueprint)

30 Friday Mar 2012

Posted by in On Technology

≈ 1 Comment

Tags

, ,

Have you ever had a house built, or an addition added to your house? Did it go like this?

*****

“Good day, Mr. Architectman, I would like you to build a home for me,” Chris VonClient said.

“I would be happy to help, Chris. How big do you want the house to be?” Andy Architectman responded, tilting his head to the right so that he could hear Chris better.

“I was thinking we needed three bedrooms and two bathrooms. So I don’t know, two thousand square feet?” Chris was not really sure what he wanted, but he had a vague picture in his mind.

“Two thousand square feet, eh? Hmm. Yes. I can see it now. That’s enough for a big kitchen, vaulted ceilings, a den in the basement, a living room upstairs. Wait, you do want a basement, right?”

“Oh, that’s a great idea, Mr. Architectman. A basement is just what we need!” Chris was excited. He could see the house better already.

“Alright then. We can get started next week. How’s $150,000 sound and we’ll be done by September?” Andy was quite sure he knew exactly what Chris wanted.

“Perfect! Thanks Mr. Architectman!”

*****

I am hopeful that when you had your home built, it did not go this way. Somewhere in this process, Mr. Architectman built out a full blueprint for the project, perhaps even with visual aids like a 3D rendering of the home so you could walk through it.

Unfortunately, too many software projects are treated like the short story above. With a few descriptive words about the project, the developer is off and running and the client is left to wait for the project to be done.

Honestly, we have done projects this way at MINDSCAPE in the past. It was a long time ago, but still it happened. It was fairly standard practice in the software industry. There are two main ways to protect against this.

The first way is something called agile development. You can go ahead and look that up on Google if you would like, but basically it means that we work directly with the client through all phases of the project. The client asks for something small and we will deliver in a week or two. That thing is then evaluated, changed as necessary and we start work on thing two. It’s a great way to make sure the client gets what they want; but it has two downsides:

1) It is time intensive for the client. We’ll need your ear and your mind a lot of the time during development. That could be a month to a year of work, and not many clients have that time.

2) We don’t know how much it will cost because we are working collaboratively on it. That means we end up charging for all of the time we put into the project. Not many clients are willing to engage in that agreement.

So, we have taken the idea of agile development and married it to a more traditional process. Once we get to development, we make sure the client receives regular updates of what we are building and they will get to play with the software as we work. We do this by breaking up a large development into multiple milestones.

But to get to development, we first have to build the blueprint, and that’s where technical design comes in. There are three benefits to the technical design.

1) The client and the developer can look at words and pictures and sometimes even partially functional prototypes to make sure we see the same ideas.

2) The developer has a better understanding of what the client wants and how long it will take to build.

3) The client can take the technical design and have it quoted by other development companies. Sure, we’d like to have their business, but the technical design ends with a solid deliverable that will give other development shops a solid way to understand the project quickly.

So what does a technical design include? Much of it will depend upon the scope and complexity of the project, but it will always include one or more of the following:

Feature List

This is present in even the simplest design documents. It lists out the features that are needed with a description of what the feature does.

Wireframes

Often, we’ll pair the feature list with a visual representation of what each page may look like. This is not intended to be a final design, but rather a way to communicate how the feature will flow and look on the page. We often use a program called Balsamiq to help this process. Here is what a Balsamiq mockup looks like.

Prototypes

Sometimes, it is necessary to model interactions or complex use cases in a more dynamic way. In this instance we will build out a prototype. This allows the client to play with the proposed solution instead of just reading about it or seeing a picture. This is helpful when there is a lot of animation or fancy user interaction with the application. It is not the final solution, as it will not have any data or logic tied to it, but it is helpful for showing what the application should do.

No two technical designs are ever the same as we tailor it to the client, the project and the scope of work to be completed. However, the technical design should make the requirements clear to the developer and the client, should allow the developers to create a reasonable estimate of work and give the clients a deliverable that they can shop to other developers.

And it’s just a good idea to build a house with a blueprint and not an ambiguous conversation.

Scheduling Sucks (Or The Problem With Rampant Success)

09 Friday Mar 2012

Posted by in On Technology

≈ Leave a comment

Tags

, ,

Life as a Project Manager at MINDSCAPE used to be pretty nice. I know, because I was a project manager for a couple of years.

We had a solid team and plenty of work to keep us busy. What made it nice is that it was manageable. Between two designers and two or three programmers, it was not so bad keeping their schedules straight.

We had a nice process. The salesperson would enter a form with the information I needed to make the schedule. I would take the form and create a Basecamp project using the information provided.

The Basecamp project would hold all of the tasks we needed to complete and the communication that we had on the project. Basecamp still works pretty well for this, and we use it daily.

Once a week I would sit down, write out by hand the hours needed for the different projects that came in, and get to work on Google Calendar. Each person in the company had a calendar, and I would put an All Day event in place for what they should be working on each day.

In this way, I could model the 4 days it would take for design, the 2 days of design revisions we would need in a week, and then the HTML and other programming that a different resource would need to do when the design was complete.

It took a little while, but it was manageable. And it was free. Each person could check their calendar each day, and know the main projects they should be working on. Here is a look at a schedule from February of 2010:

Pretty crazy looking, right?

Well, those quaint days are long gone, and yet we have not updated our scheduling methodology. We tried sticking with this process, but now there are two project managers, an entirely new department for marketing and double the number of programmers. It has become onerous to keep track of what project has priority and what each person is working on.

Want to find when we can fit a project in or get a new project completed? Good luck tracking that date down. We just don’t have it right now.

The issue came to a head over the last few weeks. New projects started pouring in, as our two salespersons worked their magic and Mike, Pete and Paul got in on the sales too. It became very clear that we needed to find something new. It was time to evolve.

So what is that something new? We don’t know for sure yet, but I have really enjoyed LiquidPlanner so far. It certainly makes scheduling a breeze compared to what we have done in the past. I have spent the last three days adding nearly two dozen projects into the system, assigning them to resources and adding tasks and estimated effort to each. And every time I add a new project Liquid Planner updates the schedule for me.

I am pretty sure I cannot go back to Google Calendar.

I will circle back to this subject in month and let you know a bit more about how we have solved the scheduling problem.

(If we have not solved the problem by then, Sisyphus and I will be best friends.)

What Makes Front End Coding So Difficult (or HTML Black Magic)

24 Friday Feb 2012

Posted by in On Technology

≈ Leave a comment

Tags

, ,

Do you know what front-end programmers dream about? It is not an answer to the national debt, or if Democrats and Republicans can get along, or even if there is life on other planets. No, front-end programmers dream of something that seems entirely more difficult to attain.

A front-end programmer wants a world where they can do their work one time and be done.

It sounds simple, doesn’t it? Most of us go through life completing a task and knowing that having completed the task, there is nothing more to do.

Not so for the much maligned front-end programmer. Before I take you too deep into their dark, esoteric world of angled brackets, cascading styles and the abomination that is javascript, it will be helpful to know what a front-end programmer is.

I am sure there are many different definitions, but at MINDSCAPE, our front-end programmers take the pretty designs from a designer and turn it into the code that displays the website in a browser. It is not enough to take the design, turn it into an image and put that on the Internet. Once upon a time the world was that simple. But it’s not 1995 anymore, and our clients want to be found on the Web by their visitors. So, our front-end programmers must turn the design into hundreds of lines of code so that automated bots can crawl the site and index the content found there.

Our front-end programmers work their magic with HTML, CSS, javascript, flash and a number of frameworks and standards that help them do their work better.

It may not be simple, but it’s a fairly straightforward process. Or so it seems, until the first time they open up the webpage they just built in Internet Explorer. That is where things start to get messy.

You see, there are a lot of browsers out there. A browser is the program you use to see the Internet. Google Chrome, Firefox and Safari are a few of the modern browsers. They are considered modern because they support many of the features from the latest HTML standards (HTML 5) and CSS standards (CSS 3). The new standards allow our front-end programmers to do really cool stuff. And when not doing cool stuff, it helps them do the mundane tasks very quickly.

Well, Internet Explorer is a bit behind the curve, and that’s sort of an understatement. So our front-end programmers find themselves in a bind. Do they build the website to use the latest and greatest technology, or do they build the website to work in what is somehow still the most popular browser (see stats at StatCounter)? And if they choose to build the website for Internet Explorer (IE), do they optimize it for IE 6, IE 7, IE 8, or IE 9. You see, each version has its own interpretations of the standards. So what you build for one, is not going to work for the other.

Perhaps you begin to see why the ritual of making a site work in IE usually begins with animal sacrifices, pounding drums and incense. It’s another reason they make us work in the Pit.

Alright, so we don’t have to go quite that far. However, there are additional wrinkles to contend with. You see, we want to make our websites so that it is easy to extend them to work on mobile devices. Most new mobile devices, thankfully, use browsers that handle the latest CSS and HTML. That allows us to build a version of the site that works for both mobile and desktop with a minimum of additional effort beyond building the mobile site styles.

In the end, our front-end programmers must build the same site multiple times if we are going to make it compatible with all possible browsers. That means each site must be:

A site for modern desktop browsers such as Google Chrome, Firefox, and Safari. IE 9 handles most of what these other browsers do, so that is a step in the right direction. However, many of the features are supported in different ways by each browser, so we still have to define rules in multiple ways.

A site for IE 8 and IE 7. These browsers are pretty close together, and most of the time standard HTML and CSS will work well with them. Either way, it needs to be tweaked.

A site for IE 6. Microsoft has finally announced that they will be killing off this browser, and the front-end world rejoiced. It’s a nightmare to work with, and for the longest time it was the most used browser in the world. Check out the Internet Explorer 6 Countdown website. IE 6 usage is less than 1% in the US now! Yay!

A site for mobile. Even though the browsers are standards compliant, we still need to design and style the site differently for the mobile space. It seems easy enough, until you realize that there are dozens of potential screen sizes between mobile phones and tablets.

Now, there are ways that we combat this without having to build entirely new sites for the different browsers but it involves trade-offs. For example, IE 7 and 8 will not have rounded borders when we finish the site. To make rounded borders, we have to create many small images to create the corner. On modern browsers, it is a line of CSS to create a rounded border. That saves us time and allows us to concentrate on hundreds of other details that make your site successful.

In the end, sometimes it is important that we fully support older browsers. In that case, we can make it happen but it takes additional time and costs extra money. If you know you need older versions of Internet Explorer to work, be sure to consult with your Web developer before starting the project.

And if you do ask him to do it and you hear pounding drums, see strange flickering lights and smell smoke coming from his room, do not go in. You don’t want to know what it takes to make it happen.

Quoting a Project (or How Deep is that Rabbit Hole?)

07 Tuesday Feb 2012

Posted by in On Technology

≈ Leave a comment

Tags

, ,

Last year I had a few rooms in my house repainted. In order to determine which company I would use for the work, I invited them to the house to quote the work. I showed them the rooms, told them the type of paint and color I wanted, and told them when I wanted the work done by.

Each company was able to calculate the amount of paint they needed, the cost of the paint and how many people would need to work on the project in order to have it done by my deadline. Having painted a multitude of rooms before my request, they were able to imagine potential obstacles before they happened and be fairly sure that they were not missing anything in their quote.

The resulting quotes were very precise and given to me with a high degree of confidence.

Quoting a job for a new custom application is a lot like that, except that we can’t see the rooms ahead of time. In fact, we can’t see the rooms, because first we have to build them. The rooms that we see in our mind’s eye are often very different from what our client sees in their imagination.

Let’s ponder a request to build a rabbit hole. The rabbit hole needs to be 8 inches in diameter, be set in a yard full of lush, green grass, preferably under an apple tree and near a babbling brook. Beyond the tree should be a field of ripened, winter wheat; golden and dancing in the breeze.

Seems easy enough, except that getting the blossoms correct on the apple tree may take some doing. But, all in all, everything is out in the open.

That is, of course, until we build that rabbit hole and take a trip inside. Suddenly, there is a rabbit late for an important date; a grinning, invisible Cheshire cat; a hookah-smoking caterpillar, a mad hatter and an irate Queen of Hearts. And let’s not even get into the pills and potions that can change the user’s size and shape at will!

The client is completely nonplussed by our discovery. Of course the rabbit hole contained an entirely new world full of anthropomorphic creatures and nonsensical laws of physics! What other types of rabbit holes could there be?

Sounds a bit far fetched, doesn’t it? And yet, similar scenes happen in the software development world all of the time.

A problem is presented by a client in a short paragraph of needs and requirements.

A software engineer conjures up thoughts of similar software that have been built in the past as a basis for their quote.

A quote is given based on myriad undocumented assumptions and risks.

Three months later, the proud software engineer presents their creation to the client and is flummoxed as to why the client is so flabbergasted at the result!

It doesn’t have to be that way, and at MINDSCAPE, we do our best to eliminate as many doubts as we can before we begin coding.

The MINDSCAPE Process

1) Our sales team meets with a client to determine what needs to be built.

2) Our quoting committee meets to understand the client’s needs. If it’s a simple project for a client that we’ve worked with in the past, we may be comfortable enough to give a fixed price cost right then. Most times, however, we need more information before we can give a granular cost. Instead, we’ll give a large range of costs based on what we know of the project, but more importantly, based on what we think may be hiding down that rabbit hole. We’ve been down there a few times and know what sort of exotic features are lurking.

3) If the client finds that part of the range will fit their budget, we engage them for a one day, on-site (if possible) requirements gathering session. Two of our team members will sit down for an in-depth discussion about what the system needs to do, why it needs to do it and what benefits are expected.

The result of this meeting is a much better understanding of the system and leads to two courses of action.

A) If the project is manageable enough, we’ll have been able to document the vast majority of functionality and even have some rough outlines for what the different screens will need to do. This will give us enough confidence to bring back a fixed cost estimate for development.

B) If the project is very large, we’ll have a better understanding of the scope of the project, as well as potential risks. The next action is to engage in a Technical Design Document phase. Based on the on-site discussion, we’ll be able to give a better budget range and a cost for the Technical Design Document. If the more-defined scope is agreeable to the client, we’ll start on the Technical Design Document.

4) The Technical Design Document deserves its own post later on, but for now it’s enough to know that our engineers will grab their spelunking gear and head down into that rabbit hole. They will survey the landscape and draw out what it is they see. The client will give feedback during this phase to make sure that we are seeing the same thing in that rabbit hole that they are seeing.

5) Once the Technical Design Document is done, we present it to the client along with a final, fixed cost price for the development. The client can then work with us to complete the development or take our Technical Design Document to another firm for quoting. Either way, we’ve done the hard work to determine what’s down the rabbit hole; for our own sake, but also for our client’s sake and the sake of any developer that may work on the project in the future.

Even with all of this due diligence, it takes constant communication and interaction with the client to make sure the project is on course. The final scope of the project can change due to many issues (who can foresee a croquet game with flamingos as mallets and hedgehogs as balls?), but we do our best at MINDSCAPE to keep ahead of the game.

(And if you have not had the pleasure of reading Lewis Carroll’s Alice in Wonderland, you should at least browse the Wikipedia article so that this blog post doesn’t seem completely off the wall.)