Software is Defining Business

Right now, today, and for the foreseeable future, software is defining business. The way in which successful businesses provide services and connect with customers is through apps, websites and APIs backed by sophisticated algorithms and analytics. Profit margins are defined by how efficient the apps are, and market growth is a function of highly personalised user experiences. This is evidenced by the growing ‘app economy’ which is disrupting sectors across the board: retail, finance, education, health, government and manufacturing.

Consumers are connected and demanding 24/7 access to services. Your customer’s first point of contact, and in many cases their only point of contact, will be via your apps rather than through personal contact. While we can thank Apple for the proliferation and general understanding of what an ‘app’ is, the definition is undergoing a transformation. Apps now encompass any software a user (or any other piece of software) may interact with. No longer constrained to just smart phones, websites are now apps that can be served on a variety of devices, as are traditional desktop applications and services provided via API’s (Application Programming Interface) over the Internet.

Never before have consumers been able to self-service needs to such a wide extent. Access to the world’s knowledge and businesses offering a staggering array of services is a few clicks away and consumer demand for apps has never been greater. This is evidenced by the announcement from Apple that the IOS app economy has created nearly 4 million developer jobs worldwide.

Business leaders must be savvy to this trend and understand the future it paints. According to CA Technologies President and General Manager for APJ, Kenneth Arredondo, “Only the strongest and most innovative companies will survive in today’s increasingly digital world”. He suggests that organisations must focus on matching the pace of innovation with the pace of disruption and capitalise on the opportunities to transform and grow during challenging times. As Marc Andreessen predicted in 2011 in his famous ‘Why Software is Eating the World’ article, innovations often emerge in the moments when it looks like everything has been changed and we’ve reached a new normal.

The message is clear: demand for app delivered services is rising, and businesses need to adapt or risk obsolescence.

Why apps are so important

Software is infinitely flexible and it’s an inherent part of our everyday lives. Our cars, coffee machines, credit cards and the expanding Internet of Things are all controlled by software. Growth is exponential – as the number of connected devices increase, the number of devices with which to connect increases, providing ever expanding opportunity. The speed and efficiency with which data can be exchanged by software is analogous to the difference between sending a text message and posting a handwritten letter.

Apps are the emerging face of business because:

  • They greatly reduce friction, increasing your capacity and allowing you to focus on other initiatives
  • Apps promote automation of repeatable, testable processes
  • An app can be crafted to provide a tailored user experience
  • They build customer and brand loyalty
  • Apps allow you to quickly and cheaply test and react to changing market conditions
  • Apps have reach: they are open for business 24/7, in any country.

The biggest keyword here is friction. For example, people will spend more when purchasing with a credit card over cash because the use of a credit card reduces friction; by separating the purchase from the cost, which has been delayed. Because of this, we foresee an upswing in credit usage with the introduction of NFC based payment options such as Android, Samsung and Apple Pay. Apps have the ability to perform the same function as the credit card in this example – they reduce friction between the consumer and supplier, resulting in increased usage, or purchases.

Automation

For existing products and services, apps provide massive opportunity for increased efficiency through automation. Recently, Kiandra was engaged by a large multi-disciplinary engineering company to undertake a complete IT transformation, starting with taking their aging but extensive customer-facing solution to a platform that:

  • Allows them to scale nationally by moving towards an API driven platform, connecting disparate systems behind a single programmable interface
  • Provides continuity of service by handling poor or occasional connectivity.
  • Leverages a responsive design to work where evidence shows their customers increasingly are – on mobile and tablet devices
  • Provides public APIs to facilitate B2B automation, increasing customer engagement and tie in
  • This investment has greatly reduced the manual effort required to process work, resulting in a faster turnaround for customers, reduced costs and increased capacity and market reach – all significant competitive advantages.

User Experience

Apps provide an immersive user experience. A beautiful example of this is the Typeform home page. Through the use fullscreen background videos and minimal web pages, Typeform engages the user, relates to the ‘human’ element and demonstrates the software. In the 15 seconds it takes to view this, Typeform have articulated their brand, connected with the user and demonstrated value in how engaging their product is, and what it can do for you. When viewed against traditional marketing activities like radio, TV and print, Typeform’s approach and ability to convert you to a customer is far superior and certainly more far reaching.

It would appear that the fundamental attraction for users to apps is that apps are self-centric. The app is there to serve you, on your schedule, in a way that works for you. Apps appeal to the inner child in us who loves to be delighted and engaged, which goes a long way to explain the frustration we feel towards poorly designed or buggy software. Apps connect directly with users on a personal level and like any relationship, should be treated with mutual respect.

Innovative Products and Services

Apps provide ground for new and innovative products and services. This is a result of affordable and portable technology, ubiquitous connectivity provided by cellular, wireless and fixed broadband, and location awareness.

New sales channels, market opportunities and ways to monetise intellectual property are frequent additions to the app landscape. Recently, we worked on a project for a large financial services company with a massive amount of intellectual property in their complex financial modelling and historical data. Having established a market exists, we were able to create a new revenue stream by wrapping their financial services up in an API and selling access to second tier providers. A second benefit was that the API could be used internally, ensuring consistency across teams – as it seemed individual teams had been creating their own spreadsheets, each which functioned differently.

Customer Trust and Brand Loyalty

Apps build trust, brand loyalty and an unprecedented ability to personalise. Personalisation is a fine line to walk between creepy and useful, especially in a post-Snowden world where consumers are becoming more privacy conscious and less tolerant of ad tracking networks in their everyday browsing. Our personal rule of thumb is this:

Delight me with a recommendation or incentive based on information I’ve explicitly given you – my browsing and purchase history on your site, and we’re good. Track me outside of your domain, and I’m no longer your customer.

It’s also important to be transparent, disclosing exactly what information is recorded, and giving customers an option to opt out, or have their information removed. Online ecommerce platform Shopify’s feature for allowing a ‘guest checkout’, without first having to create an account is an excellent example of providing customers a choice relating to having their purchases tracked.

Who’s Investing in Custom Development

At Kiandra, we engage with companies across a number of industry verticals and find our customers have a number of elements in common. It starts at the executive level with a clear business goal and a strategic directive to use software products and digital solutions to reduce effort, automate processes, provide timely information and drive profits.

We’re seeing a large amount of interest in B2B companies looking to automate through the development of consumable APIs. Providing an option for B2B customers to directly integrate in-house systems with their supplier is an attractive proposition on both ends. The supplier creates dependency through entanglement and the consumer gains access to the raw information and is able to integrate it directly into their business process and systems – often greatly reducing manual effort in the process.

The Engineering Industry

Engineering has a large number of complex problems that are time consuming to solve and critical in nature. Engineering companies are recognising that automation tools and software can do a large amount of the ‘grunt work’, which is improving overall accuracy and helping reduce timelines in large project schedules.

Education

Education is currently being revolutionised through software and app development, with courses being delivered online via edXKhan Academy and iTunes U. Education institutions have adopted learning management systems for delivering course work, connecting teachers and students, and accepting work submissions. There are also education apps for people of all ages.

Government

Government has always been keen to adopt technologies that save money. Peak bodies are embracing apps as a way to cost effectively develop and deploy standards and processes across their member organisations.

There are three key factors that result in myriad opportunities for Government right now:

  • Cloud providers Amazon Web Services, Microsoft Azure and Rackspace all have data centres on Australian soil, addressing the most often quoted barriers of latency and data sovereignty. Access to commodity compute and storage resources, security, logging and auditing is fundamental to supplying to Government and as a Cloud concern, these aspects are all standardised and supplied out of the box.
  • We’re seeing more Government departments embracing Agile methodologies. Agile focuses on delivering business value based on prioritised needs. A significant aspect of Agile is about forging client relationships and developing trust through customer collaboration.
  • Governments collect massive amount of data with which they have limited resources to leverage. Appification or enhancing Government services with their own information (check out data.gov.au) is a great opportunity.

The federal government’s launch of a Digital Service Standard is an encouraging indicator that opens the door for state and local government to embrace the digital app economy.

Financial

Financial service providers are also investing in custom development. As discussed earlier, we’re seeing monetisation of intellectual property through the creation of subscription based APIs. We’re also seeing a large amount of self-service consumer facing apps – automated, small loans being the most common. Finance companies typically have well defined processes and a ton of paperwork. Digitisation of the data collection and evaluation processes is a major opportunity for increasing business agility, insight through data analysis and reducing manual effort.

Regardless of sector, any company that has the following concerns would benefit from investing in application development:

  • Getting the right information into the hands of users in a timely fashion.
  • Automating a process, or the collection of information.
  • Having complex problems solved.
  • Improving customer service.
  • Having more resources working on their core business, rather expending effort on repetitive tasks that have little value.

Barriers to Investing in Apps

The top five obstacles to investing in application development include:

  • Budget constraints
  • Security concerns
  • Lack of resources
  • Lack of knowledge and/or skills
  • Lack of executive management understanding benefits.

The reason budget constraints tops the list is that custom development can be expensive and the historical failure rate of IT projects does little to inspire confidence. Here’s a couple of tips on how to help approach the expense issue:

  • Establish the monetary benefit of your goal first. You want to understand the cost/benefit as quickly as possible. If a mobile app initiative is worth an extra $500,000 in sales each year, then that informs your maximum viable budget.
  •  Reframe the project from being an ‘IT Project’ to a ‘Business Project’. The goal should always be to deliver business value. When establishing scope, it’s easy to get carried away with ‘cool to haves’. Measuring each feature against the business value gives you a control mechanism with which to cut scope, reducing the size of the budget you require.
  • Start small and demonstrate value with a smaller project, building confidence to tackle larger initiatives.
  • Application development is a capital investment. You’re investing in an asset that will add value to your business. Consider financing development like you would any other capital purchase.
  • You will likely have monthly support, hosting and maintenance costs so include an operational budget as well. Like any other asset, software requires maintenance and upkeep to stop it from deteriorating.
  • Measure return from derived value. I recently scoped a mobile application for a supplier of safety equipment. The application provided a number of quick calculators for determining the loads that the company’s equipment could bear. The purpose was not to make a profit from the app, but rather to put the equivalent of a branded slide rule in the pocket of every one of the company’s customers. From a marketing perspective, the derived value exceeded the cost of development.

Security

There’s an average of 4 million data records lost or stolen every day, so it’s no wonder security is a major concern for many people. Opening one’s virtual doors increases the number of vectors available for attack, therefore it makes sense to:

  • Include security testing as part of your application development process.
  • Conduct regular security audits across your organisation.
  • Keep security policies updated to reflect current recommended practices.

The best way to increase your in-house teams skills, knowledge and capacity is to bring in a supplier for a specific project, especially if you’re under resourced. Software development practices and technologies advance very quickly and it’s likely that, in order to stay relevant, you’ll need to be learning at least one new major technology every two years. Software development houses have to do this to stay competitive. Some of the most enjoyable projects we’ve worked on involved augmenting in-house development teams with hired project teams – which was a great way to cross train, modernise practices and ensured a shared knowledge base. The in-house team were confident in their ability to support the app once the project team had left.

The Costs of Not Investing in Custom Development

Unless you have a captive market, the biggest risk of not investing in application development is dwindling market share though the ability of competitors to deliver better and more cost effective services.

It’s no longer enough to just have a pretty website, businesses need to demonstrate value and innovation.

Tips on How to Select the Right Supplier

If you’re considering investing in application development and want to bring in a project team to assist, here are few tips to help select the right supplier. Before you start, establish the following:

  • An outline of what the business problems are and what success would look like. Don’t worry about technology (unless you have specific constraints) or how you will achieve success yet.
  • An estimated budget. If you don’t have this, engage your supplier to help you ascertain one and be prepared to pay for it. For an estimate to have any degree of relevance it will require discovery, data collection and knowledge transfer. Whether you go ahead with your project or not, this information has value and requires effort to achieve. Free quotes are great for curtains, and useless for knowledge work.
  • Decision makers have scheduled availability to attend meetings with suppliers. You’re trusting a company with your business, judge their value and competence in person.

Ask the questions ‘What would I get for my budget, and how would you achieve it? How would this differ if we had twice the budget, or half the budget?’ Remember, you’re establishing cost benefit, and with software, there is typically more than one way to skin a cat. Varying your budget allows you to understand the trade-offs and helps determine what the minimum viable product should look like before committing your entire budget.

The right supplier should engage with you on a business level. Application development is not commodity work that can be thrown over the fence. If you want a quality outcome, be prepared to invest your time and seek out suppliers who question ‘why’ as they’re demonstrating a willingness to understand your business drivers.

Finally, look for a supplier with established practices in a number of disciplines:

  • User Experience (UX) Design
  • Project Management
  • Development
  • Quality Assurance
  • Security
  • Analysis
  • DevOps
  • Infrastructure.

Building a successful app is a team effort and having access to pool of talented and skilled professionals will be highly beneficial.

Advertisements

Opinionated Software

Consider:

Enterprise > Medium to Large Business > Small business

As a product’s target market moves from right to left in the above diagram, its configuration and customisation options grow and become more sophisticated and complex. This makes sense, as an organisation becomes larger, it’s more cost effective to change the software than it is to change the people and the process, so the software must be customisable to meet Enterprise needs.

This also has the effect that to the right of the diagram the software can afford to be opinionated. That is, the software can say ‘this is the methodology and process that we follow and support, and to get the best results, you should too’. Opinionated software will still provide configuration options (everyone needs something a little different) but the underlying philosophy is that it’s cheaper to change the process and people to the meet the software. As software moves towards the Enterprise end of the continuum, it becomes less opinionated and more generic as it’s required to cater to a wider degree of needs – relying on configuration and customisation to allow the enterprise to enforce its opinions on the software.

Both approaches have implications worth considering when choosing off the shelf (or custom) software for your business. The question to ask is, is it more economical to change my processes, or change the software?

Single or multitenant for your SaaS?

Often we need to make a call between architecting for single or multitenant instances when designing Software as a Service (SaaS) products.  Under a single tenant solution you deploy one instance per customer and under a multitenant solution many customers share a single deployed instance (where ‘an instance’ is all of the server resources you need to make the product available, e.g. web server, database, email server). It’s costly to change architecture once an application has been developed, deployed into production and has live users – so picking the most appropriate architectural approach from the outset is important to ensure longevity and maintainable costs. The following offers a number of considerations in helping decide which approach is appropriate for you.

 Single Instance considerations:

  • Physically ‘more’ secure – as each customer has a separate instance (likely including database, web servers, and storage) the risk of leaking data between instances is significantly reduced
  • Performance can be tuned on a per customer basis. Have a client with heavy loads? Scale up, or out. A load intensive customer won’t affect the performance of other clients as the resources are not shared. Got a light work load? Scale down, reducing cost.
  • Deploying to an on-premise, or hybrid cloud location is an easier story if you’re already set up to deploy as  single instance model. The nature of single instances means that an instance can be created and deployed as a single package – assuming the target deployment environment supports the required services and any other dependencies, e.g. web server, database server, virtualisation and / or network services (SMTP, DNS routing), runtimes (.NET, PHP)
  • Instances can be deployed in different regions to reduce latency (increasing performance by moving the instance closer to users), or to meet local compliance laws, e.g. data sovereignty
  • Calculating per customer hosting costs is simple as it’s based on exact, actual resource usage
  • Per customer [instance] customisation can be achieved if required. For that customer who just has to have that specific feature. Note: this will complicate your source control and deployment models, and can lead to a fragmented nightmare if not managed effectively, or avoided all together. Just because you *could* customise a solution per customer doesn’t necessarily mean you should!
  • Monitoring, maintenance, backups and new version and/or patch deployments and/or data migrations need to be managed on a per instance level, increasing costs proportional to the number of instances.  Need to back up instance databases, or roll out an update? Consider how will this be managed, and the cost for 1, 10, 100, 1000, 10,000 instances.  This is a significant cost, and should be evaluated against the necessity and likely usage of the other benefits of this model
  • Have a clear picture of how new instance provisioning will be managed, and how long it will take. Most cloud platforms allow for automated provisioning via API’s, and you may need additional steps like registering or configuring external services like DNS and authentication mechanisms (e.g. AD accounts)
  • Some resources can be shared, e.g. worker queues for background processes and SMTP servers. Plan which resources need to be ‘per instance’, and which make sense to share across instances

Single instance is typically suitable for:

  • Applications that store highly commercially sensitive, or personally identifying information of a private nature
  • Customers with specific, and varying workloads
  • Customers who need to adhere to local compliance laws
  • Customers willing to pay a premium for these features as they incur a higher cost to provide and manage

 

Multitenant considerations:

  • Careful consideration needs to be made to ensure data is not leaked across clients. This isn’t difficult, and should be managed with suitable design and sufficient testing
  • Deployments are much simpler, everyone can always be on the latest version. This approach lends itself to providing an ‘evergreen’ product
  • Reporting across all your instances is much simpler when they are in the same place (or all the data is in the same database)
  • On-boarding new customer is typically simple as it doesn’t require the provisioning of underlying resources (servers, database, storage)
  • An outage will effect *all* of your customers, design for redundancy
  • Requires a single monitoring, maintenance, backup and deployment approach. Costs will increase with the number of tenants, though much lower that a per instance approach. It’s probably the biggest benefit to this approach
  • There could be a point where you need to scale up, or out – or have *very* large data and need to consider how to partition. This could be one multitenancy per region.

 

Multitenancy is typically suitable for:

  • ‘Self Service’ products scaling up to and greater than 1000’s of customers
  • Reducing costs of deploying, hosting and maintaining your service

Shared tenancy with individual database and/or storage

An alternative hybrid approach is to provide shared tenancy of the application, with separate storage per customer. For example your app could be load balanced across a number of web servers which would service all of your customers. Each customer however would have their own separate physical database for data storage. This approach gives you the ability to provide the physical separation of data while having a shared application tier. This approach takes benefits from both single and multitenancy architectures:

  • Physically ‘more’ secure
  • Storage can be located in different geographic regions (though be aware any latency this might introduce in your application)
  • Retains ‘evergreen’ application versioning
  • Overall costs are lower than single instance approach

Calculated Columns using IF and IN operators in Zoho Reports

Filed under #SoIDontForgetHowIDidThis, #Zoho

In Zoho Reports you can’t add lookup or standard columns to data sourced from Zoho CRM. You can however add calculated columns, which is great if you want to transform a list of usernames into a department for future filtering or grouping.

The syntax for this isn’t well documented, and it took a wee bit of fiddling to figure it out. We combine the IF function with the IN operator where:

IF is a function defined as:

if(expr1, expr2, expr3)

Returns expr2 if expr1 is true else it returns expr3

Example: if(5 > 10,100,50) = 50

IN is a list operator defined as: 

<expression1> in <expression2>

It’s also useful to know that lists are enclosed in round brackets (), string literals are enclosed in single quotes ‘’ and column references are  enclosed in double quotes “”.

E.g, to return the department name of a user based on the potential owner, the formula would be:

IF("Potential Owner" IN ('Anthony','Seth', 'Chris'), ‘Technology Infrastructure' , ‘Software Development’)

Which will result in a list similar too:

  • Seth – Technology Infrastructure
  • Bob – Software Development
  • Carol – Software Development
  • Anthony – Technology Infrastructure

For a more explicit result we can nest the IF function, which will be familiar to many Excel users:

IF("Potential Owner" IN ('Anthony','Seth', 'Chris'), 'Technology Infrastructure' , IF("Potential Owner" IN ('Phillip’,'Bob'), 'Software Development' , 'Other’))

Will result in:

  • Seth – Technology Infrastructure
  • Bob – Software Development
  • Carol – Other
  • Anthony – Technology Infrastructure

As Carol isn’t explicitly defined as being in the TI or SD departments, this is more correct.

So how much will that cost?

The most common question I get asked by prospective new clients is ‘How much willMyBigProject cost?’ This is no surprise, as custom software development projects require a reasonable investment and you want to know what the AsLittleAsPossible cost will be so you can justify your business case and return on investment.

References to lengths of twine aside, ‘How much will MyBigProject cost?’ is by far the hardest question to answer. For the most part, because there are multiple ways to implement any solution, and I don’t know what’s important to you. So I ask you a bunch of questions, like whether you value time to market over feature completeness, do you have a specific budget in mind or do you need to scale / support high availability? (This is the modern day equivalent to asking if you want it fast, cheap or reliable, pick 2). What it comes down to is a 30 minute conversation and then I’m going to make an educated guess.

The formulae for my educated guess is pretty simple: scale the size of the team to match the scope of MyBigProject and multiply the result by the number of person weeks I think it will take to achieve. Which I’m hoping you will agree with me in a few moments is a thoroughly stupid way of estimating AsLittleAsPossible.

What’s wrong with this approach is that it is so laden with assumptions that there is no way it could possibly result in value for money.

At one end of the assumption scale is where we assume that only exactly what you asked for is required to be estimated. Most people have little experience with commissioning custom software projects, and it’s unfortunate that this is often taken advantage of by what is commonly known as the race to the bottom.  The theory goes, that by only estimating *exactly* what has been asked for, the work can be won ‘cheaply’, and everything else can be charged as a variation. Imagine building a house and on moving in day you discover it has no internal doors, no plumbing, no floor coverings, and while you specified a loft, you didn’t specify that you wanted a staircase to connect the upstairs with the down. Sound far-fetched? The media is ripe with IT projects that are over budget by orders of magnitude because of ‘race to the bottom’ tendering.

At the other end of the assumption scale is where we over anticipate everything you haven’t specified, and allow provision for it. To my detriment, this is the side of the scale that I tend to lean towards as I hate having to go back and ask for more money. If I give you a price of AsLittleAsPossible, I feel you should have the expectation thatAsLittleAsPossible will be all that is required to complete MyBigProject, and because I’m reasonably conservative, and as a company we value engineering awesomeness, we have on occasion over-provisioned and come in well under-budget.

Which brings me back to why asking ‘how much will it cost’ isn’t in your best interest, and a stupid way for me to estimate MyBigProject. You can get hit with never ending variations, or overspend more than was necessary to actually realise MyBigProject.Both approaches leave you spending more than you had too, and that sucks.

Asking me (or any vendor) ‘how would you achieve project MyBigProject for AsLittleAsPossible’ allows you to measure the value you will get in return for a set amount that you specify. Not only does this make comparing across vendors easier (interestingly it also allows you to measure expected effort, which is a great indicator of the calibre of your vendor), but it allows you to adjust AsLittleAsPossible up or down to understand the trade-offs, or extras involved.

Start with an amount that you would like to spend, I recommend 10% to 20% less than your break-even point. I like to do this with car shopping.  What can I buy for $20,000 right now? Well, I could get a 15 year old supercharged Mercedes, or a 3 year old Mazda Rx8. Both meet my criteria for a sports coupe, one I can service myself, and the other is far newer and has more recent technology. From here, I can evaluate the pros and cons of each vehicle, specific to my needs. I can assess the market, adjusting for where I see value and like Goldilocks find what is just right.

By working collaboratively in this manner, we start to break down our assumptions, uncover what we don’t know and shape the approach around the areas that you see as having the most value.  My favourite example of this is an eCommerce solution I architected where the majority of the budget was spent designing a beautiful, intuited shopping experience – while the back end administration was implemented in Microsoft Access. For the client, it was far more cost effective to train 5 people to use Access and far more valuable to provide a market leading online retail experience for her customers than it was to follow conventional wisdom and implement a homogenous solution.

What I really love about this approach is that it challenges us to think creatively to come up with the best solution for you, based on your priorities. We let you know what features can be implemented, and how they will be implemented for AsLittleAsPossible. If that’s not enough to meet your minimum viable product, adjust AsLittleAsPossible to include the bits you want (you kept back that 10% to 20% right?)or if it’s getting a little too fancy, scale AsLittleAsPossible back. You’re now in the driver’s seat, and able to evaluate the merits of a solution against exactly what you wanted to spend in the first place, no sticker shock or awkward negation required.

So for MyBigProject, try starting with AsLittleAsPossible and challenge your provider to design a solution to fit your budget.

Scoping for readability and automatic clean-up with IDisposable()

This is a simple trick that I find makes my code more readable, and reduces the amount of code I need to write to explicitly scope *something*. It avoids the need to have to manually clean up, or reset some state. In the sample below I’ve used this to highlight the output on a console app to a user defined font colour. It’s really simple, DRY, and a great example:

Rather than writing this:

Console.WriteLine("Starting...");
           
Console.ForegroundColor = ConsoleColor.Yellow;

while(!_server.IsComplete)
{
     Console.WriteLine(_server.Progress);
     System.Threading.Thread.Sleep(1000);
}

Console.ResetColor();

I can now do this:

Console.WriteLine("Starting...");
using (new ScopedConsoleColour(ConsoleColor.Yellow))
{
      while (!_server.IsComplete)
      {
          Console.WriteLine(_server.Progress);
          System.Threading.Thread.Sleep(1000);
       }
}

Based on a defined class of:

class ScopedConsoleColour : IDisposable
{
    public ScopedConsoleColour(System.ConsoleColor colour)
    {
        Console.ForegroundColor = colour;
    }

    public void Dispose()
    {
        Console.ResetColor();
    }
}

mplementing IDisposable ensures your state gets reset based on your scope. Another common use for this approach is for setting a wait cursor in a Windows form application. I’m sure there are many others great uses!

While this example is trivial, and only really saves 2 lines of code – I find it helps maintain readability as my project size increases, and reduced bugs if I forget to reset state because of an unexpected execution path – like when an exception gets thrown.

How to engage a software development company – Part 5 – How to specify requirements

Following on from what was covered in Parts 12, 3 and 4 we now I’ll look at how to specify requirements.

The clarity with which you can articulate your requirements will directly affect the depth of response your supplier can give you.  With this in mind, I’m going to provide a reusable template that you can use to specify your high level requirements that’s easy to remember, quick to do and will give your supplier a deeper understanding than the clichéd specification scrawled onto a restaurant napkin!

Here’s the template:

As a __________

I want to __________

So that __________

For example a small, online web store selling low volumes of widgets to the public may specify the following high level requirement:

As a store owner

I want to receive an email when a customer submits an order

So that I can print the order, so it’s ready to be filled

Depending on the size of your project, you’re probably going to end up with several dozen of these, so it’s advisable to start with a table:

The reason this template is so effective is that:

–          It identifies the roles present in your project. Understanding the different roles builds a picture of the different people that will interact with your solution, the concerns that they have and the actions they are likely to take.

–          It provides detail to the abstract. Stating ‘I want an online store’ is open to a wide range of interpretation. Specifying who can do what in your online store is measurable and can therefore be estimated.

–          It provides an opportunity for you to review your project within the context of your vision. For every item you should be able to answer the question, ‘How does this contribute to my project vision?’ If the item doesn’t contribute to your vision you’ve either identified a reason to refine your vision, or identified a feature for which the cost to implement should be evaluated against the actual value it brings to your project.

–          It provides an opportunity for a third party to review your project within the context of delivering it as a solution. An experienced supplier will be able to review your requirements and discuss recommendations on technical and implementation approaches, highlight items requiring clarity or additional detail (in the above example, how does the customer pay for the order of widgets?)

In essence, to solve a problem you first need to understand it. Following a systematic research approach allows you to establish the facts and expose the underlying goals and tasks which will support the development of a solution that is fundamentally focused on the needs of users.