The services that I offer, prior to the selection of a software development vendor to build your system, include the following:
Clarifying hosting requirements & options
- Should you host your system yourself, or have the vendor host it, or use a third-party hosting service?
Minimizing vendor dependence
- Your ability to independently re-build your own system from the source code if your software vendor goes AWOL.
- Avoidance of any vendor-specific technologies.
- Clarification of any license or distribution issues.
Helping to create the Functional Specification.
The clearer the specification, the less chance there is of a misunderstanding causing later problems.
- The critical distinction between 'Must Have' and 'Nice to Have' features.
- How to avoid 'feature-creep' - the primary reason for software systems being delivered late.
- Timeline estimations.
- Helping to create a project outline to present to candidates.
Project Structure Recommendations
Definition of an initial Proof-of-Concept
- A simple, working deliverable from the vendor can test their claims of code quality very early in the project life-cycle.
Question: How does a software development project get to be six months behind schedule? Answer: One day at a time.
I can help you avoid this happening.
Software developers do not always refer to the Functional Specification document when writing code. The longer that your
chosen software vendor works without you seeing the result, the greater the risk of them building something
that is not what you need. The best way to avoid this happening is to agree to have regular, incremental
releases which you can view and test yourself.
Milestones with source code delivery
There should be clearly defined 'milestones' during the development process, where for each an assessment is made
to determine whether the project is on-track, and if not, to work out why. If the payment structure of the business
relationship with the vendor allows it, the source code written for the system to-date should be delivered to you
at each milestone.
This protects you from a situation where the vendor suffers some catastrophe and cannot operate,
or their key personnel leave the company taking all knowledge of your system with them, or if you are unhappy with
their performance and want to switch to a different vendor.
Intellectual Property (IP) & Source Code ownership
If after your completed system has been delivered, you decide to end your relationship with the vendor that built it,
it is vital that you have all the system's source code, so that further enhancements to the systems can be
implemented, and any bugs found and fixed.
Similarly, if the hosting platform where your system is running has a catastrophic failure, you need to be able to
re-deploy the system to an alternative platform, which may imply having to rebuild it from the original source code.
Either way, it is critically important to ensure that a) you have access to all of the source code used to
build the system, and b) you own all of the IP for the code, so that you are free to modify and distribute it
as you need.
If you contract a low-quality software development vendor to build your system, the project may fail as a result.
The most important services that I offer are those listed here, designed to minimize the possibility of this happening.
Clarify geographical factors
- communication across different time zones
- the need for face-to-face meetings
Search for possible candidates
- Required technical expertise
- Required business experience
- Review and follow up on references
- Produce a short-list of candidates
- Schedule the first Vendor Call for each short-listed candidate.
Vendor Calls - I can be present during vendor selection calls, or provide you with pre- and post-call support -
whichever you prefer. Either way, if possible these calls should be recorded, so that verbal commitments and claims can be subsequently confirmed.
An architect-level representative from the candidate company needs to be present on the calls, and must be willing to commit to be
personally involved during the entire project.
First Call - High-level Topics
The first vendor call would be discursive, covering some of the following areas:
- Present a recap of the high-level project deliverables
- Establish clear points of vendor contact (PMs, Architects, Team Leads, Developers)
- Clarify preferred platforms & technologies
Discuss vendor's philosophy for software architecture
- Modularity of different components
- Centralization of common logic/code
- Choice of database
Understand vendor's development environment
- source code control
- management of database schema changes
- security for offsite workers
- Review vendor's coding standards, including code comments and external documentation
Discuss and clarify IP/code ownership
- Code transfer on milestone payments
- Confirm willingness to produce 'proof-of-concept' to backup claims of technical quality (see below)
Second Call - More Technical Depth
If the first call goes well, a second call will be scheduled to go into more technical detail:
- Solicit input about examples of the vendor addressing real technical issues/requirements
For a system whose data is stored in a database, the database itself is the 'heart' of the system, and the correctness
of the design (the 'schema') is critically important. If the schema is wrong, it will be difficult - if not impossible -
to ever write efficient code against it.
Client involvement - irrespective of your own technical knowledge, if the database schema is not understandable to you,
it is probably wrong.
- Normalization v Performance - how to balance the two.
- Approach to error and exception handling
- Ask specific technical questions about problems solved
- Ability to quickly illustrate UI concepts with private releases
What is the vendor's testing strategy? For example, do they adopt a formal regression test of the entire system
before deploying a new version into production?
Is there a dedicated testing team, whose goal is to stress-test the software to the point of trying to break it? It is
not sufficient to leave all the testing to the developers that write the code - all too often they will only test scenarios
that they thought of themselves, and catered for in their code.
- Willingness to deviate from original specification if requirements change
Bug tracking and Release strategy
- How are bugs reported, and what is the process of ensuring that they are fixed?
- If a show-stopper bug is discovered in a production system, how to identify which release introduced it
- How is the system 'rolled back' to an earlier release?
Ask the vendor to agree to build a simple 'proof-of-concept' application, as a demonstration
of their ability to back up their claims of code quality by writing high quality code.
- The proof-of-concept should implement a simple task related from the functional specification, so it won't be wasted work
- I will evaluate the quality of the design, code and documentation for the proof-of-concept
- Any concerns raised by evaluation should be discussed on a call with an architect/senior-level developer from the vendor
Finally, I will make a recommendation of which of the candidate vendors to select.
Post-Vendor Selection - System Implementation & Release
Congratulations! You've selected a software development vendor that has demonstrated their ability to understand your business goals,
and to build, test and release the system that you need to achieve these goals. The difficult part has been done, so why else might
you need any help from me?
Review of database schema
The database is the heart of a data-driven system, and its design (the 'schema') is critically important to its overall
operation. If the database schema does not accurately model the business world of the client that it is intended to
support, operational problems will almost certainly occur. Prior to starting the software writing phase of a project
the schema should be carefully assessed to make absolutely sure that it is correct, and if there are errors or
omissions they should be addressed before any coding starts.
Based on an understand of the client's business model I will be able to confirm whether or not the database schema
does accurately reflect this model. And based on the planned functionality of the system I will be able to identify
any potential performance bottlenecks in the schema.
Weekly Status Updates
A software vendor's Project Manager (PM) keeps track of the progress of projects, continually working with the development team
to make sure that a development effort remains on track. Without this scrutiny projects can start to slip, falling further and
further behind schedule. At the start of a project the PM should create and share with the client a project timeline - a
chronologically ordered series of milestones during the development process - to be used during the project to confirm project progress.
There should be weekly status meetings between the client and the PM, where, based on the project timeline, it is determined whether
or not the project is progressing as per the planned schedule, and if not, to quantify and track the slippage. If a project is
slipping further and further behind schedule, it is important to understand why, and to rectify the problem as soon as possible.
Claims of project progress should be backed up by both interim releases where functionality can be seen to be working, and
presentations of the completed code that supports the functionality. I will be able to confirm that the presented code is
indeed complete and production-ready.
Regular Code Reviews
Having committed to write high quality code, a software vendor should of course follow through on this commitment, ensuring
that all code written conforms to the promised level of quality. Policing the quality of work done by a team of developers,
however, is difficult. It can be tempting, too, to move more senior developers to new projects, introducing less experienced
staff into an existing project team, which can lower the quality of code being written.
When a development team is under time pressure, there is a higher risk of code quality suffering as a result of shortcuts being
taken, or code being released without the necessary testing.
By periodically reviewing the code written by the development team I will be able to spot any deterioration in quality, and raise
this as a concern, before it becomes a problem.
All software development companies need a formalized, centralized repository for reporting and tracking the bugs discovered during
the development and post-release operation of a software system. There is no reason why such a system should not be made available
to the client paying for the system. Indeed, there should always be an option for bugs that are discovered by the client themselves to be
entered into the bug reporting system.
By periodically reviewing the process of bugs being discovered and fixed, I can identify areas within the code-base which seem
particularly prone to bugs. This in turn may indicate more fundamental flaws in the design of the underlying logic, which need to