Level 6, 122 Walker Street, North Sydney 2060  |  (02) 9993 3300  |
Posted 14th March 2018 by Lawrence McCrossen

Many of our clients have heard of Agile for software development, but some are confused as to what it is. They know it involves building software in stages, which is normally I good idea, but that’s hardly makes it a distinctive approach.

There are of course, many flavours of Agile, and we have our own at The Bridge...

Agile Development

In my view, for an approach (note it’s generally not referred to a as methodology) to be considered Agile, it must:

1 Involve a phased approach

2 Consist of working software right from the start

3 Embrace change, and not attempt to define all the functionality of the software up-front 

4 Involve close and continuous collaboration between clients and developers

‘User Stories’, ‘Sprints’, ‘Scrums’, ‘Paired Programming’, ‘Velocity’ etc all have their place, and are features of successful variants of Agile.

It is not the same as prototyping, which is a common confusion. A prototype might certainly make sense when you need to test a concept with a small or minimal version of the ultimate system, but it need not involve (2) or (4) in the list above.

At The Bridge, we’ve adopted the four points above for our approach to Agile, but in addition we pay particular attention to feedback for the client on time spent, which of course equates to time to deliver, and cost.

This is particularly important because a concern that clients have with Agile is that they can’t budget a fixed cost up-front project, or if they do fix the budget, they can’t guarantee a complete set of requirements being delivered. Of the course, the difficulty/impossibility of defining a set of requirements up-front, that won’t change, is at the heart of the Agile approach, but the apparent open-endedness of the project is still a concern.

To provide more assurance, the feedback we provide to our clients is not just the progress of the project itself, but details of the activities, time used, category of work etc (essentially old-fashioned timesheets). As you’d expect, this is used for billing, but it goes beyond the concept of person-days, and helps both us and the client understand the ongoing nature of the project.

If you'd like to discuss your website or software development options with The Bridge, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 15th December 2017 by Lawrence McCrossen

Software Development Management

We sometimes work with clients that are new to software development. This might be because they’ve worked in other areas of their business, or because they are involved with a start-up, which of needs a website that will be an integral part of the business.

"What Process?"

We’ve talked about ways of specifying systems previously in our blogs http://thebridgedigital.com.au/blog/5-ways-to-spec-a-system and http://thebridgedigital.com.au/blog/software-development-specs. These are still relevant, but we also have to be mindful of the fact that if a client hasn’t been I involved with software development before, they may not understand the need for a specification process - “we can just tell us what we want, and then leave them to it”. 

So this has to be explained carefully upfront. Even when using an Agile methodology, it may be misunderstood as an easy way to avoid writing a big spec. In fact, Agile has many benefits, but it is extremely dependent on frequent client input.

The same applies for ongoing tracking – planning, review and testing. Ideally one should use one of the many online project and task management systems. But if that isn’t practical, then at least an Excel or Word document that records issues and progress in one place. Again, it may be assumed by a client new to software development that progress just happens because the developers are experienced and experts. We are experienced experts, but a bespoke development is almost by definition, a new development, and so in that sense has not been done before.

It's not like a Product

One common misconception that we’ve seen is that a bespoke development is much like a ready-made product, in that the developers go away and build it, and when it’s finished, the client gets some training and then starts using it. That would be nice, but the nature of software development is that the software being produced is new. Hence it’s a very creative, interactive process, involving the best ideas from both the experts in the business you are aiming to improve, and the software developers that will ultimately bring the system to life.

As always, a discussion and setting of expectations up-front helps immensely. A little time spent explaining why methodology and process is important will pay off in spades, and you can look forward to creating software that will become the foundation of a new business.

If you'd like to discuss your website or software development options with The Bridge, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 19th April 2017 by Lawrence McCrossen

At The Bridge we both manage and consult on website and software development projects for many industries, including financial markets, media, automotive, and government.

Whatever the industry, I’ve noticed a number of recurring pitfalls. Note that I’m assuming at least a basic level of project management, for example a plan, structure, stakeholders etc. If you don’t have those, then there are plenty of publications you can refer to, and if course there is just common sense. 

The mistakes I’m going to describe in this series are from our real experiences with website and software development projects we’ve seen over many years.

Project Management

Planning Adjustments not carried out on an ongoing basis

Project plans look great at the start, and are often the basis for business planning and contractual agreements. I won’t touch in the contractual side here, but from the point of view of managing the project, the project plan frequently gets abandoned after the ‘real work’ starts.

The problem is that no adjustment of expectations is made when components of the project are held up. The end date is kept the same, in the unjustified hope that time will be made up.

At the very least the plan should be pushed back based on the dependencies of the delayed task. A good project planning tool will help with this. 

However I would argue that a further adjustment needs to be considered, depending on the cause of the delay. If for example certain parts of specifications, or content creation have taken longer than expected, then this might indicate potential delays in other areas of specification or content. This may be due to certain personnel being unable to spend as much time on the project as expected, or maybe they were just overly optimistic in evaluating the task. Hence there could be a case for extending the time required for future tasks, unpalatable as this may be.

The ‘Long Tail’

What I mean by this is the time needed after the system is essentially built, and is being tested, or refined on the basis of the user experience. This can drag on for much longer than expected, as even seemingly small changes can take time to implement, or maybe the right resources aren’t immediately available (see my previous blog ‘5 Reasons Why Building Software isn’t like Building a House’this part actually is a bit like building a house). For a website there might be a long wait for a legal/compliance review of the final site. Maybe most of the project personnel aren’t busy, but the project still can’t go live. The better the upfront specification and design, the less likely this is, but in my experience it’s very difficult to avoid. 

Testing nearly always involves, well, testing, but it also involves fixing and changing, which takes time. Best to just allow for it in the plan, and don’t assume testing can be rushed through at the end of the project.

If you'd like to discuss your website or software development options with The Bridge, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 12th April 2017 by Lawrence McCrossen

At The Bridge we both manage and consult on website and software development projects for many industries, including financial markets, media, automotive, and government.

Whatever the industry, I’ve noticed a number of recurring pitfalls. Note that I’m assuming at least a basic level of project management, for example a plan, structure, stakeholders etc. If you don’t have those, then there are plenty of publications you can refer to, and if course there is just common sense. 

The mistakes I’m going to describe in this series are from our real experiences with website and software development projects we’ve seen over many years.

Project Management

Plain Underestimates

This sounds so obvious, but it’s so easy to underestimate how long things take, whatever the task. To make it harder, software and website development normally involves creating something new, and in their enthusiasm people base their estimates on a best case (or even less).

This is difficult to prevent, but I’ve found that peer reviews of estimates are useful, and as a manager it’s wise to consider the worst case!

Part-time Resources

This is related to ‘Simple Underestimates’ above, but more to do with the proportion of a person’s time that can be spent on the project, rather than the number of hours or days it will take to do if that person did nothing else. 

More often than not, a software development project will involve specification, development and testing by people who also have other work, or even a whole other ‘day job’. This makes a lot of sense in that for example you will benefit from testing by a person that is currently familiar with the day-to-day processes of the business. But if that person is unexpectedly landed with urgent extra workload, the project will take second place. 

The only solution here, apart from using dedicated resources (which isn’t always practical or even desirable) is to plan for it – again, consider the worst case.

If you'd like to discuss your website or software development options with The Bridge at no cost or obligation, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 11th April 2017 by Lawrence McCrossen

At The Bridge we both manage and consult on website and software development projects for many industries, including financial markets, media, automotive, and government. 

Whatever the industry, I’ve noticed a number of recurring pitfalls. Note that I’m assuming at least a basic level of project management, for example a plan, structure, stakeholders etc. If you don’t have those, then there are plenty of publications you can refer to, and if course there is just common sense. 

The mistakes I’m going to describe in this series are from our real experiences with website and software development projects we’ve seen over many years.

Content not considered early enough

This relates particularly to websites. Requirements are gathered, followed by beautiful designs created and approved for the developers to build. Templates are set up in the Content Management System, and filled with Lorem Ipsum (dummy text), to be replaced with the real content some time later.

The problem with this is that different content will influence which designs will work best. A simple example is where the amount of text doesn’t match the space provided for it in the template.

So content needs to be an integral part of the design. Designers and content providers need to work together early on in the project.

All Stakeholders not involved early enough

This issue occurs in all types of software development. The project is set up to include relevant stakeholders, and everything appears to work smoothly, with decisions made along the way to the final release. 

Then someone, normally a senior manager for client, sees the nearly finished product for the first time. He or she had previously approved the project to go ahead, and had delegated the details to someone, but not spent any time at different stages of the project cycle. This is fine, but if the senior manager doesn’t like what they see, then substantial rework may be required.

This is particularly an issue with public facing technology such as websites and mobile applications, where the company image is at stake.

Once again, early involvement is crucial, with the right people.

If you'd like to discuss your website or software development options with The Bridge at no cost or obligation, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 25th January 2017 by Lawrence McCrossen

You want to build software for your portfolio/risk management, compliance, market making or perhaps investment/operations reconciliation. So you design, plan, build and you’re done, just like building a house, right? 

I used to hear this a lot from our clients in the Finance Industry, although not so much these days since Agile has become more popular.

So why isn’t it the same? Why can’t we make accurate plans the same way they do in the building industry? 

Building a House

Leaving aside the fact that building construction doesn’t always go to plan either, there are some key differences, in reverse order of importance:

Number 5…

For larger, longer projects, such as major portfolio management or risk systems, business requirements may change under one’s feet. That doesn’t happen so fast with buildings, and if it does it’s too late to change anyway!

Number 4…

It’s generally easier and cheaper to change software than it is hardware – so people do change it! There’s an expectation that things such as security types compliance rules will be added and altered because it can be.

Number 3…

Technology changes fast in the world of software, and that can lead to uncertainty in development timelines as unexpected issues arise. The finance industry is subject to rapid change too, in as markets evolve and regulations are adjusted (normally tightened).

Number 2…

It’s extremely difficult to envisage the entire system behaviour up-front, there are so many degrees of freedom, if not infinite for even a small sized system. This is particularly the case if current operational processes within a financial services organisation are being reconsidered as part of the project. Houses tend to be more straightforward functionally. This is of course a key reason why Agile methods are popular.

And the Number 1 Reason building software is not like building a house…

Software systems are often unique, and being designed for the very first time, more like new type of building than a new construction which is a variation on something previously built. Many financial systems are available off-the-shelf, so if a fund manager, trading operation or bank is building a bespoke system, it is because their processes, trading or risk management is proprietary and by definition the system has not been seen before.

If you'd like to discuss your software development options with The Bridge at no cost or obligation, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 23rd December 2016 by Lawrence McCrossen

You may have heard about it over the past few years. Launch is planned for the second half of 2017 and interest is certainly heightened. 

I won’t provide an explanation of the concept here – the New Payments Platform Australia website www.nppa.com.au launched in December provides plenty clear information and many useful references and videos.

New Payments System

Australia certainly won’t be the first country to adopt a fast payments systems – several others including the UK, Japan, India, Brazil, Republic of Korea, Switzerland and others have been around for a number of years. However, Australia is at the forefront because the really exciting part is that Australia’s version will be one the most innovative (or to be more precise, facilitate innovation). 

Of course it will be fast – but one key advance is potential for Overlay Services – additional data and context over and above the very basic transactional information. An analogy is the difference between texting and content rich emails and apps.

What kind of apps? It’s difficult to know, but of course anyone can think up of ideas, the same way they have for smart phones.

Who will build them? Banks of no doubt, but if the NPP enables new entrants to the marketplace, the possibilities are endless.

Security? The speed and ease of payments has been reported in overseas versions as resulting in exposure to fraud. But in the case of the Australian version, with its overlay services and additional information, there is opportunity for solutions – maybe an app that does some security checks, or additional information required payees.

Expect to hear a lot more about the New Payments Platform Australia as we approach launch date later this year. 

If you'd like to discuss your software development options with The Bridge at no cost or obligation, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 20th November 2016 by Lawrence McCrossen

What Does Your Cloud Look Like

The Cloud has steadily revolutionised our world in recent years, perhaps in a quieter way than smart phones and Social Media.

It’s a very broad subject, and I won’t attempt to cover all areas. I’ll focus on a number of small to medium sized clients that we know, and can add insight based on our experiences working with them.

What about security?

A detailed analysis is not the purpose here, but I once heard a Microsoft speaker say that they spend a billion dollars a year on security. Of course Microsoft are a big target, but it’s hard to argue with that.

It’s true that in a sense you lose control of your data in the Cloud, and it’s a good idea to have some kind of backup strategy in place, but can you really convince yourself that it’s safer in your own rack?

There is the question of sovereignty, but many services now guarantee that data won’t be stored overseas.

So, what are the flavours?

1 Selected Applications

The first point to make is that many companies have been using Cloud based systems for many years, it’s just that they referred to them as ‘Web Based’. Everyday products like Salesforce, Survey Monkey, Mailchimp, and many, many others.

Something like Zoho Apps aims to provide every application you could ever need – all in the Cloud. Our very Seymour product for automating and displaying spreadsheet data to websites run fully in the Cloud. 

2 Basic Business Tools

Major change has come with Google’s office products. And the highly significant Microsoft 365 – basically you can completely remove your (high maintenance) Exchange Server hardware and software, and enjoy all the tools – email, contacts, calendar as you did before, but without the worry of what happens if your exchange server goes down. The move for a small organisation is relatively simple, and I from our own experience at The Bridge, you won’t look back!

3 Business Applications

Excludes standard applications such as Word, Excel here, or any application where user interface is tied very closely to the data stored (see 4 below).

Pseudo Cloud – just taking an application and running it on Cloud server, using a remote access tool like Citrix. It’s cloud for the purists, but it does get the application off your in-house infrastructure, which is one of the reasons for having the Cloud.

This aside, you don’t have to have web based application to benefit from the Cloud in a more sophisticated way. At the Bridge we’ve built complex desktop applications that install locally on PCs and laptops, but with the database residing in the Cloud. With some security built in, you can use the system from anywhere you have the application installed. And the database is truly pay-as-you-go in Cloud fashion.

The only word of warning is it be aware of external connectivity of your applications – this may be affected when you move server based components.

4 Files and Standard File-based Applications

In spite of being the simplest conceptually, file storage can be difficult to work out. My experience is that keeping a small server (or just a storage box) on your local network will consistently give you the fastest file retrieve and save, but the difference may be minimal.

Where it matters is for some file-based applications, such as complex spreadsheets or other file types that have many links to other files or services. This can be very slow outside of a LAN. If you are considering this, you should test thoroughly first.

So if like we do, you decide to keep some local storage, you can then use the Cloud as a backup location for the files.

I imagine one day Internet speeds will be consistent and fast enough as to be indistinguishable from a LAN. 

5 ‘Thin’ Desktops

Another option is to host everything – I mean everything, from files, common applications though to email clients in the Cloud. Access is either by Remote access to an application running in the Cloud, or a cloud version running on a browser. But I haven’t heard of this working well, and I imagine it could get quite costly. And it really wastes the capability of your desktop or laptop.

How do you choose?

With the possible exception of Thin Desktops, you can mix and match as you wish. The costs comparison will likely involve sunk costs of existing systems versus immediate ongoing fees, plus the initial cost of the move. Backup strategy will also need to be considered.

In my mind though, the long term benefits of having reduced infrastructure, pay-as-you go, and reduced support headaches, are in most cases compelling for the first 3 flavours, and the 4th flavour in some cases.

If you'd like to discuss your software development options with The Bridge at no cost or obligation, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 20th October 2016 by Lawrence McCrossen

You’ve decided you need a system developed, or perhaps a new website.

What next? How do you turn your business objectives into clear instructions for software developers to create a system that will fulfil your needs?

Software Specifications

1 Write a Spec 

The traditional approach is still used widely. Sometimes it’s used in conjunction with other approaches, eg writing small specs during Agile development, sometimes referred to as ‘Stories’.

My view is that you should always start with some kind of written statement of what you intend to develop. Doing so focusses ones thoughts and leads to further insight.

Problems can arise when too long is spent on this stage and either the business has moved on in the meantime, or the level of detail is more than can be reasonably worked out without reviewing a prototype or an initial phase of the development.

Is there a template for writing specifications? Yes, there many, but no one of them could reasonably by regarded as a standard for the industry. At The Bridge we have our won which we modify depending on the kind of system eg website, interface etc. A quick online search will reveal many to choose from.

I recommend you choose a template that is closest to what you are doing, and make sensible modifications that will enable you to ask the right questions. You should also ask your developers what they would like to see.

Then start writing, but don’t overcook it.

2 Agile

Agile is more than just writing software in smaller stages. 

There are different flavours of Agile, but the key characteristics are small stages (often called Sprints, typically of 3-6 weeks each) and production-ready software at the end of each stage. 

So it’s not the same as prototyping, or just breaking up a large project into smaller pieces. There also has to be usable software at the end of each phase.

At the heart of the Agile approach is the notion that it doesn’t make sense to try to specify large systems up-front – it’s too complex and subject to change as business requirements themselves evolve.

Of course by definition, you can’t accurately estimate a full set of Agile phases that represents the end goal. Only the individual Sprints are estimated. But the client can stop at any time, they aren’t committed to a long multi-period contract.

Once the principles are accepted, Agile can work very well. The only issues I’ve seen are when the client underestimates the involvement they need to commit to. Frequent iterations means constant feedback in the form of requirements (or Stories) and testing. 

So accept the principles, and stay involved!

3 Develop a Prototype

Prototyping is another approach that reduces risk by taking smaller steps, but it differs from Agile in that it’s not intended to be a production system at any point, and there are no real guidelines as to how the process is supposed to work. 

It’s an obvious way to go if what you are doing is breaking new ground, or you need a proof of concept.

I’ve seen it work very well using Excel as a way of specifying a system that contains a lot of complex calculations. The business user may be skilled in the use of Excel and so can quickly create and modify formulae until they are happy with the results. Then the development team working on the full system can more easily emulate and compare during testing.

In the right situation, with appropriate business users involved, this approach can vastly reduce risk and development effort.

4 Templates

This is commonly used approach for developing websites, rather than developing a bespoke site from scratch you can choose from a selection of templates.

Of course your websites will look like hundreds or even thousands of others, but if that’s not a problem then there is the potential to reduce costs and timeframe.

The other issue is that it may not be easy to add more complex functionality later on, so choose carefully. 

May also be a good temporary solution, to be replaced later on as the business evolves. 

5 Leave it to the Developers!

This might sound very risky, but in certain situations where talented developers understand the business very well, they are able to create useful applications, sometimes that the users of the systems hadn’t thought of.

Obviously this kind of development needs to be kept under control, with frequent deliverables. It shares features in common with Agile in that management overhead is kept to a minimum, and timeframes are short. 

If you'd like to discuss your software development options with The Bridge at no cost or obligation, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 07-03-2017 by Lawrence McCrossen

Seymour is simple solution to a common problem – how to move data held in spreadsheets onto your website in an automated way. Check out the interactive graph below, produced by Seymour.

The Problem

For years we’ve seen organisations such as Fund Managers go through a manual daily process of receiving Unit Price and performance data from their custodian in the form of emailed spreadsheets, checking the columns of data, and then keying the data into the website content management system.

Even for a small organisation with minimal amounts of data, this approach is prone to error, or even being missed altogether if key personnel are unavailable.

In addition, even when the data arrives on the website, it is often displayed in a drab, tabular and non-interactive fashion, with visitors to the site having to download and examine the data themselves if they want to do more than just view a list of numbers.

Our Solution

Seymour is a solution that completely automates the process, from receiving spreadsheets via email or FTP, extracting the data you require from the spreadsheet(s), and displaying the data on your website in a stunning graphical format (you can still have tables of data if you want).

In addition the system checks that daily data has arrived and alerts key personnel if it hasn’t. Tolerance checking is also provided to help protect against erroneous data that may occasionally be received.

Highly flexible

A key feature of Seymour is its flexibility. Any type organisation can use it, not just in Financial Markets.

There setup process is very straightforward. The user of the systems firstly sets up the names of the objects and fields, and their types, according to the type of business. These objects and fields can be anything you want.

The second step is to provide an example ‘template’ spreadsheet and map the columns to the Seymour objects that have been created in step 1.

The final step is to insert a ‘link’ or ‘code’ on the website where you want the data to be displayed.

Once the system is set up the way you want it, the process will happen automatically every hour, day, week as required. You will of course be informed if data hasn’t arrived or appears incorrect.

Secure Cloud based, no local installation

Seymour is hosted in a highly secure Cloud environment, with access to the portal login via browser. An audit trail is kept of all files loaded into Seymour.

Low pay-as-you go, easy setup

After an initial straightforward setup, payment is made on an as-you-go on a monthly basis. No infrastructure is required on your site, and Cloud hosting and licensing to use the software is all included in the fee.

If you'd like to learn more about our Seymour product, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 1st August 2016 by Lawrence McCrossen

I love spreadsheets. Spreadsheets are wonderful things, I use them all the time, and so do our clients. But it can be difficult to know when to stop using them.

When the subject arises with our clients, the issues are the same for both large and small organisations.

Consider a boutique Fund Manager using an in-house developed complex spreadsheet for managing portfolio, orders and risk. This might make perfect sense when starting up – low cost of technology, developed by an investment manager who knows exactly what they need and how to maintain the spreadsheet.

As well the business grows, and the spreadsheet is adapted and evolves with it – the same as any other software. But there are some problems specific to spreadsheets.

What's wrong with spreadsheets?

It’s more than just data input Errors

This is certainly a problem, as data validation is limited, and there is always the risk that a formula gets accidentally overwritten. That said, it’s also possible to make input errors using technologies other than spreadsheets, so it’s not actually the main problem that distinguishes spreadsheets.

Security, in more than one sense

  • It’s just a file - the spreadsheet file can be copied and taken
  • User access can be restricted, but it’s difficult to create an audit trail of who has used the spreadsheet


  • Of course, anyone can use it, but there is limited ability to control who can use which functions via roles and user ID’s
  • Maintaining consistent data is very difficult. Other than protection from writing over the whole file, there is no ability control over when different users edit specific parts of the spreadsheet. One client told me that the way they handle this is to shout across the room to let other know that a spreadsheet is about to be edited!

Database – history and audit trails

While you can of course store a large amount of data in a spreadsheet, the ability to update that data in an automated and consistent way is limited. New rows can be added, but only in a very simplistic way, and relationships with other data are difficult to maintain (see below). This makes historical reporting very difficult to do.

Keeping an audit trail of when and how data was changed is not something that can be incorporated into a spreadsheet. This obviously an extremely important issue for risk management and auditing.

General Robustness

One of the great benefits of spreadsheets is that data and formulae are placed in the same place ie cells of the sheet. It’s so easy to just start typing data in and manipulate it with formulae right next to the data. For more complex logic, you can write code too.

The problem arises when data gets moved around or added in ways that the writer hasn’t foreseen. Sometimes errors indicate the problem, but it’s easy to point to the wrong cell without knowing, or even to completely overwrite data!

If you are struggling to maintain your spreadsheets, The Bridge can advise on how to restructure or even replace them with a more robust technology.

If you'd like to discuss your software development options with The Bridge at no cost or obligation, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 21st March 2016 by Lawrence McCrossen

How do you specify a system for a software development project? In the majority of cases clients do not have a detailed set of documents describing the system that they’d like to build. Hence we are often asked how this can be done, and whether a standard way of doing this exists.

The short and correct answer is “no”. We do use some templates which ask key questions and guide the client in the process, but there is no single approach applicable to creating a spec for a business software application.

To clarify, we are referring here to the development of a substantial system that requires complex business logic, probably with a database containing fairly complex data structures, not, for example a simple website that can be created using available template designs. Nor am I referring to systems on the other end of the scale, such as NASA space guidance systems!

Software Specifications

If you search online for spec document templates or workflows you are unlikely to find what you are really looking for. The reason is that there is no one-size-fits-all approach. Why?

  1. The multitude of delivery platforms – desktop applications, browser based and mobile devices, all from different vendors, makes it difficult to standardise the user experience
  2. Many companies don’t have time and resources to create a detailed spec at all, let alone a spec based on a standard
  3. The often used Agile methodologies discourage the use of detailed up-front specifications. Instead they recommend small project iterations that can be easily described in plain language, which is translated into code by the developers
  4. It’s very difficult, if not impossible to completely or even partially specify a system up-front, mainly because it’s often something that hasn’t been done before. So it’s not surprising that having standard to follow doesn’t help much – a standard for what?!

So what do we do at The Bridge - leave it to chance? From our experience, there are a number of things we can do, depending on the circumstances:

  1. Use prototypes – if you can create something that looks like what you want in say Excel, this gives our developers a much better idea of your vision. In fact Excel works particularly well where there a lot of calculations involved eg financial markets tools
  2. Even if you don’t have time and resources to write a detailed specifications, at least spend time writing up key points of what you expect in terms of user experience, information flow, and of course functionality
  3. For bespoke websites (ie non-templated), use standard Content Management Systems and graphical files for designs

Lastly, as with all aspects of project management, always keep involved in the development process, whether from within an agreed Agile development approach, or a Waterfall methodology. Interpretation of requirements is crucial, however they are communicated, and the only way to ensure that the software is in line with expectations is to review regularly. Very regularly!

If you'd like to discuss your software development options with The Bridge at no cost or obligation, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au


Posted 20th August 2016 by Lawrence McCrossen

Bespoke Design

We often meet businesses looking for a system that will help their business, but they aren’t sure whether to go out and review what’s in the marketplace, or look to develop their own.

These days of course, virtually all businesses use off-the-shelf technology for their general needs such as email and collaboration, accounting, timesheets, and billing. Our involvement is normally in specific systems that are used by individual industries, such as financial markets, media, automotive, government, sport etc. It’s within the scope of a single industry or type of business that the decision becomes more complex.

There are a number of reasons why businesses start to look for systems:

• Start-ups requiring a system to run some aspect of their marketing or operations

• Growth in an existing business requiring a change or more efficiency in process 

• Dissatisfaction or limitation with current software

• A change in a business requiring new or unique processing

• Software products are your business

With the exception of unique processing, all of these situations warrant a review of existing systems that may fulfil a similar need. This is true even when software products are your business, because it may make sense to license existing software, perhaps with your own branding or front-end.

So how do you go about making the decision?

Here are some questions to ask:

• How generic are your requirements? 

Unless your business is intending to take on the likes of Microsoft or Google, exceptionally few businesses would have need to develop a dedicated email system, but your requirements might be more generic than you think.  If they are then it’s likely there will be many good systems available in the marketplace at reasonable cost (or even free in some cases).

• Are existing solutions expensive? 

Possibly a vendor has a strong market position and well-regarded platform, but often it is because the software that is available includes many features and functionalities that you will not need and cannot be licensed without those additional parts. In this case it may make financial sense to develop a cut-down or more specialised version of an existing product. Several of our clients in financial markets fit into this category – systems are available but they only require a small subset, for example for compliance reporting of a specific kind.

• Are your requirements truly unique, or close to? 

Here’s where you will obviously consider a development. It’s likely that your business itself is also unique, and hence the software you use will become an integral part of your competitive edge. There are examples of this on our website – a media planning system that was required for planning and measuring buying effectiveness. There was no such system available because the approach to the business was unique. Or a video sharing website providing full control over advertising revenue to channel owners.

• Are you a software vendor yourself? 

In this case the decision is complicated by the fact that if you buy off-the-shelf software to re-package yourself, you will need to establish licensing agreements for branding and distributing that software. Also, you may need to control the future direction of this software, which you can only do if you own the source code or are allowed to modify it yourself (such as with most open source components)

• You need to control the future direction of the software 

Whether you are a vendor as above, or a company whose fortunes depend on the ability to evolve internal processes at your own pace, you can only really do this if you own the source code and are able to direct future development.

• How quickly do you need a solution? 

Normally bespoke development takes a lot longer than setting up an off-the-shelf product, even where a lot of customisation is needed. These days the wide availability of Cloud-based systems has speeded up the setup process massively. Another option might be to use an off-the-shelf solution for the short term while building a more suitable bespoke version. This has the advantage of easing the pressure on the bespoke development project timeline.

• Are you unhappy with your current system? 

Whatever the reason for your dissatisfaction, it may be time to look around. Hopefully you will have a good enough idea of what you need (and don’t need) that you can make a highly informed decision, and provided your existing solution sat least gets you through the day, you have time.

So, build or buy?

The best reasons to buy are:

• The functionality is very generic, and you don’t need to ‘reinvent the wheel’

• Cost – this partly relates to the point above. Software development can be expensive and time consuming, and it may be a lot cheaper and easier to license software already available in the marketplace

• Timeframe – if you need a system very quickly then buying one readily available in the marketplace may be your only option in the short-term

The best reasons to build are:

• Uniqueness – your business or process is very unusual, or in the case of many websites, it needs to look unique

• Control – you need to be able to make changes at will (you could of course buy the source code, if available, to achieve this)

• Lower cost – this will normally only be the case where you only need part of a bigger system that is already available off-the-shelf

How can we help?

The Bridge are passionate about building software to help our clients’ business’ grow. 

At the same time, we appreciate that a development project may not suit you at this point in time, but we know what high quality software looks like and we can help you to assess off-the-shelf products.

So please contact us if you are looking for a new system, whether your inclination is to buy or build, we will provide an honest, unbiased assessment. 

If you'd like to discuss your software development options with The Bridge at no cost or obligation, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 14-03-2017 by Mitch Brown

In a previous blog Responsive Design vs Mobile Websites we explored the differences between dedicated mobile sites and responsive design. 

These days, either a dedicated or a responsive website is a given, but where do native mobile apps fit in if we are developing for Financial Markets?

While a mobile site or responsively designed site is intended to be viewed in a mobile internet browser (such as Safari on the iPhone), a mobile app provides a different experience, with the trader or investor downloading and installing software directly to their phone via the Apple or Google Play stores, or directly from the developer in the case of an App for corporate in-house use.

Mobile apps are generally designed to provide a specific functionality, with a more narrow focus than a mobile website.  Mobile apps should not be viewed in opposition to mobile sites but as a complimentary part of your online strategy.

Mobile apps are able to take advantage of native functions of the phone such as geo-location and notification systems to deliver information to its users. Mobile apps can also interact with other software on the phone. Mobile sites, on the other hand, are restricted to the phone’s internet browser and will not be able to provide notifications to users if that browser app is closed. Hence mobile apps providing market data feeds and charting functionality are a better solution as they will utilise specific features of the mobile device.

Examples of this are Bloomberg and Yahoo Finance apps, and various Twitter client apps that exist for iOS and Android phones. These apps will remember your login credentials and allow you to track portfolios, financial news and market data, or send messages and post tweets to follow other users. 

They are able to run in the background and provide notifications to your phone when market conditions change, receive messages, or connect to new followers through the system. The apps can also use your phone’s geo-location data and access other data such as the camera or photo library. While these organisations’ mobile sites could be used through your phone’s web browser as well, a mobile site would be unable to provide this level of interactivity. 

Native mobile apps are able to provide a fully tailored experience, without the constraints that browser-based apps or sites can suffer from. Particularly in the case of iPhones where there is minimal deviation in the hardware, mobile apps can be designed with the best User Experience practices in mind without much concern for cross-device or cross-browser compatibility.

So what’s a good use case for a mobile app?  

Think about a core feature of your website or business that is utilised on a regular basis by you, your clients or potential clients. 

In the case of a stock trading app, creating an app that delivers your online database of previous trades and portfolio holdings would be a great choice. The app would then be able to notify investors about trading opportunities directly via their phone’s notifications. Users won’t need to remember URLs or rely on browser Bookmarks to reach your service – they simply load up the app from the phone’s home screen.

An App may also be of benefit when a user has no access to the Internet. This is not often the case these days with plenty of free Wi-Fi available, but it does happen!

In these two examples, the same functionality will probably exist on your desktop and mobile site as well, but of course, mobile apps can also provide exclusive functionality not found elsewhere. For example users of an app will benefit from location based services.

What’s involved in mobile app development?

There are two main approaches to mobile app development. 

Best practice is to develop apps directly in the native language of their intended delivery device. Apps for Apple smartphones and tablets use Objective-C and, more recently, the Swift programming language. Android apps are written in Java. 

By utilising native code and functionality, these apps will provide the best performance and usability. The downside of this approach is that you will require two apps for the main mobile platforms (more if you wish to include Microsoft and BlackBerry), each with different code bases and distribution methods.

The other approach is to use mobile “wrapper frameworks” such as PhoneGap or Trigger.IO that will allow the use of HTML5 and JavaScript to create the app. The app is then bundled up inside a “wrapper” compatible with iOS and/or Android.

This has the advantage of being able to use one HTML5 codebase for your app, with only the third party wrapper system requiring additional code and updates. This also means your app will be much faster to develop. The major downsides are that, these apps tend to run slower than those written in native code and because of the “one-size-fits-all” approach, will not be able to make the best use of all the phone’s hardware features.

So do I need one?

While a mobile website is essential for your business, mobile apps are a case-by-case consideration. For many businesses, a mobile/responsive website is all that is necessary but where a suitable use case exists to deliver a service to your customers via an app, then it should definitely be a part of your mobile strategy. Mobile users spend around 30% of their time in apps as opposed to the browser, so these can be a great way to keep customers engaged with your business.

It’s also common for Apps to be the front-end of a business model in themselves. Users are used to paying for a downloaded App, or for an upgrade to a free version. If this is your intention, then of course you will need to assess the business opportunity vs costs etc. as you would with any other venture.

If you'd like to discuss your mobile app or site development options with The Bridge at no cost or obligation, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au.

Posted 20th December 2014 by Lawrence McCrossen

Welcome to ‘The Bridge Digital Solutions’ blog!

We write software, we build websites and we create apps. We were doing this for years as part of Tango Technology.

We have been operating as a separate company for 12 months now, and have fully settled into our new offices in North Sydney, but we’ve been too busy developing clients’ websites to spend time on our own site blog!

As an introduction I’d like to explain how we work with clients, designers and SEO experts to build compelling and effective websites.

Working with our Clients

Our website page http://thebridgedigital.com.au/why.html shows examples of our work.

At the initial stage of a website development, clients often want to know what is possible before they commit to a brief – how much content they will be able to access and change themselves, how we will store videos, what is involved in creating a secure login for their customers to access, what options are available for hosting.

As website builders this is where we provide crucial input to our clients’ decision making. For a complex website we maintain this dialogue throughout the development process so that all key decisions are fully informed.

When we are presented with a client’s branding and graphical design, we often work closely designers in order to maintain the integrity of their creative work….

Working with Designers

In our conversations with designers they have told is that the most important things they want from developers is the ability to communicate, and a willingness to adhere to the creative concept. We achieve this not just because we know the technology very well, but also because we enjoy the challenge and ultimately we want the client’s website to both look great as well as benefit from rock solid engineering.


Once you have a website you obviously want people to visit it! Paid links from the likes of Google AdWords is one way. The other is from ‘organic’ search.

After that, optimising your site for organic search is a specialised area of expertise and involves ongoing care and attention to keep your rankings high. We work closely with SEO experts to ensure that the basics are done, including the correct use of META and H tags for your content to ensure that each page to be indexed has an appropriate, search-friendly title and correctly coded headings in your content. We can also integrate tracking and reporting features such as Google Analytics, Crazy Egg and Omniture.

Feel free to call us for a chat on 02 9993 3300 or email lawrence@thebridgedigital.com.au