Software entrepreneur's starting up checklist

We’ve been helping software entrepreneurs for the past 15 years to build their apps and bring the products to market. Helping startups is in our genes, as we started out with helping fledgling silicon valley startup get back on its feet. And over the past one and a half decade we have helped more than 20 startups get their products released.

We know it’s never a easy journey, it’s hard for the cash strapped entrepreneurs to make decisions about what to build and what to leave out, when and how to release their products, how to get their first customers and how to improve the product from those customers’ feedback. We have helped them navigate these murky waters, and in the process we have learnt a lot. Over the years we’ve blogged a lot of our experience that we want to share with with would be entrepreneurs and today I’ll try to distill our thoughts to almost a checklist of things that every software startup owner should be aware of before starting out on their bumpy ride.

0) Know the basics of software development

It’s the zeroth item in the list because it’s expected. Don’t get into a business unless you know the basics of that business - simple. This doesn’t mean you have to know Python programming or need to know how to SQL join. It’s great if you do (and many of our startup owners do because they were software developers themselves) but your role when you are wearing the entrepreneur hat does not need you to do them and actually it’s better not to know them with that hat (but you might be wearing the developer hat on other times - remember many startups are just a person show!). As an entrepreneur you need to know the basics of how things are done, what fits what and some basic tools. 5 Tools all non-technical software founders should use is a great starting point, but a little more googling will you great tutorials. Khan Academy is a great resource, here’s one that I give out to non-techie owners to start with: What is programming?

1) Find the right developer

Now that you know that you want to build the app you need the people to build it for you. The first step is to decide if you want to outsource this or if you want to hire your own developers to do it (or of course if you want to write it yourself). Deciding to outsource your development or not is a guide we wrote sometime ago to distill our ideas around this. It’s usually straight forward to decide but if you decide to get an external company to build the app for you a much harder question is to find that vendor. How to select a software vendor? gives you some of our thoughts around this, and Testing an outsourcing partner is our cheat sheet for checking on your vendor.

2) Setup the right contracts

Once you found your vendor you’ll need to setup the contracts that protect your software and your product deliveries. Software development is a fluid process, where you need space for both you and your vendor to change and adapt as you progress through the development. Too tight a contract will make this process difficult and bring up frictions that are hard to remove leading to a bad software or no software at all. Too flexible a contract and you are at risk of getting a bad deal or a really bad product. Our article 5 things every software contract needs shares our ideas of coming up with contract that works.

3) Run the right process

When the software is being built there needs to be a set process for interacting with the developers. You’ll need to monitor but not start breathing down their necks. You’ll need to prioritize, guide and help the team navigate with your business priorities in mind since the goal of the software is clearly to bring in business but you’ll need to be careful not to derail things in the way. Not an easy task, but 5 things a software entrepreneur must remember gives out some of the advice we give to our startup owners.

Top software company in Bangladesh

We became 15 this year. Starting from a small startup with just four people to one of the top software company in Bangladesh has been a long journey. There is a lot that we have learnt on the way and in today’s blog is about the lessons we have learnt in journey to becoming one the best software company in Bangladesh.

It is all about the developers

A software company is as good as it’s developers. And if we don’t hire the best developers, if we can’t keep them motivated, if we can’t keep them trained and happy we will fail. This is the very core of our philosophy at Kaz. Everything we do, every policy we adopt, every rule that we set, every decision we take is based on this core concept. We test if our change will make life harder for our developers. If it does we will always discard it. This formula has made us one of the best places to work and grow as a developer in Bangladesh.

Hiring the best

There is no way around this. A software company is only as good as the skill of its people. If you don’t hire the best talents there is no way you’ll be the best IT company around.

The real challenge in hiring the best is of course finding, attracting and retaining the best talents. That’s a full time work for a company. It is not something you can stop and start once is a while. This is something that has to be in the top of any long term or short term strategy that the company adopts.

We think we have been relatively successful in attracting the best talents in software and IT in Bangladesh. We’ve have written in the past about some of our “secrets” (not really any secret though, just common sense). Here’s one about our interviewing process that has helped us a lot: The dumb interviewer

Keeping the edge sharp

Software is such a field that if you are not up to date you are simply not good enough. To be the best in software development you’ll need to keep your talent always up to date with recent developments in technology. And this something that we do as a priority.

Knowledge is something that you can’t just tick a box and it gets done. You need to setup a system that automatically encourages people to learn and makes that process a constant thing. We have various methods for this, starting from simple seminars and workshops to multi-day training sessions and code camps.

We were the first company in Bangladesh to bring in internationally renowned trainers and speakers to train our staff. Our multi day on site training with people like Naresh Jain, Industrial logic, IBM research faculty, various university faculty members and our internal senior staff has made a huge difference to the skills and expertise of our employees.

A creative work environment

Now that you have the best talents and they are all trained to go don’t think that would automatically lead to the top software company. The missing piece in this is the setting the backdrop for your talents to work in. A work environment for creative space such as software development needs to be tuned, so that the software developers feel comfortable and creative. There is a multitude of things that you have to do to make this work and we have written extensively about what we do at Kaz to make this happen. We think the start is setting up the physical work space, here are some details about what we do in that aspect: work space design for a software company . Once you have the physical aspect covered you need the not so tangible team effects to kick in, here is an article we wrote that describes this element: recipe for a great software team.

And then there needs to be close eye on the culture of the teams. We have always been careful to monitor this and trying to quantify it (not an easy task for sure).

I think these elements has enabled us to deliver amazing software products over the past 15 years. Making us one of the top software and IT companies in Bangladesh. Here’s a quick facts numbers I stole from one of our presentations. Companies from one person startups to Fortune500 giants trust to make their software solutions.

That’s it for today!

"VIVE Vibe" - making the first VR game

As with the rest of the software world we were excited about the possibilities of VR and getting our hands dirty with some VR code. So it was with a big smile on our face that we took in our first official VR project. And not just any boring "also ran" VR app but a full blown first person shooting game!

Nothing compares to writing a game. Add to that the total immersive environment of a HTC VIVE (our first target platform) you have something that literally stops us from living in the reality of this world :)

I'll be writing here about our experiences in this first serious dabble in the world of VR. Here are somethings that we wish we knew from the beginning...

 

 

Virtual reality is a whole new ball game

Duh! That should be obvious. But if you think about a software company that has been around for 14 years, you'll realize that we are a group of people that has seen really wide range of technical innovations. So we just assumed (the wort possible word in our profession - as we learned once again) that most of our experience would translate to this new platform. We soon realized that although coding skills (e.g. Unity or C# skills) translate pretty well but as soon as you hit anything Ux be it GUI, interactions or usability you have to learn everything from scratch. The total immersion of VR and the closeness of that experience of that with everyday human experience leads to a complete rethinking of how the software should interact with the user. Mr. Cooper, a new About face is sorely needed.

Interfaces are your friend

I mean the Interface constructs the programming languages. VR hardware is still at infancy. Just like every other hardware race, several companies are fighting it out with their own set of hardware, SDKs and way of doing things (mostly bugs :) ). So the code you write needs to have a way to be abstracted easily so that you add new hardware support without rewriting the core game logic. And that's where all those OOP skills will come in handy. A simple rule we use is to keep asking "what if I switched to Rift here?" and that helps give perspective. So go for all the IPlayer, IScorePack, Ix you can think of!

Get early feedback

OK this is really ancient advice in software, but we felt that in VR software this is even more true than other spaces. Again, because of the closeness to everyday human experience and the immersion in a VR application (particularly a game with realistic graphics) it's very easy for users to assume they know exactly how (and where) things should be. Gone are the old escape routes that techies used to take like "Windows has their Cancel buttons there" or "right click is always context menu". As soon as we got our first broken version out we found that even team members were complaining about how a certain thing was being picked up or how a door was being opened. And it's obvious, these are things we have learned over years of real experience, there is a universally accepted convention out there for basic things like "picking up an object" and you cannot mess with it! So schedule demos at every point of the project, run usability sessions, even better run Joel's hallway tests at every opportunity you get. 

OK on that note let me leave with some of our "hallway tests" put together in a little video by our design guru.

I'll be sharing more of our VR development experience here, so watch this space!

5 Tools all non-technical software founders should use

Many software companies are run by founders who are non-technical themselves. As long as they have a technical team that is strong and reliable things work out just fine. However, there are some tools that the non-technical founders can use to make the software development process even smoother. These are tools that the techies themselves use but many founders shy away from them thinking of them as something that is "too techie". A little time investment on learning the basics of these tools could bring in huge improvement to how the software is made and delivered. These tools can save time and money by communicating early feed-backs and decisions in the software development process.

In our experience as a software development consultancy that has helped dozens of startups all over the world build out their products there are some tools that are absolutely vital for all the stakeholders to use - techies or non-techies. We insist that our customers use them, we even run training sessions for non-technical stakeholders to learn the tools. 

Today I'll run through my list of top 5 tools that every software project stakeholder should learn and use.

1. Issue Tracker

This is the easiest one to use. All software team use an issue tracker (or at least that is the least we can hope for). There are numerous very good trackers out there, what you choose depends on your taste and need. There is, for example, reliable workhorses like Jira or Fogbugz or super simple trello or if your team is all for mods - trac; the list is really endless here and it doesn't matter what the exact tracker is as long as it serves the team's need. Whichever tool they are using it's relatively simple to learn for a non-technical user and then start using it to stay in touch with what the development team is working on. The tracker is perfect for putting in early feedback on features, keeping track of what feature gets done when and to communicate with the developers within the context of particular tasks.

It is hard to list all the benefits of bringing in all the stakeholders to the issue tracker. It simplifies pretty much all conversations, takes away all the nasty surprises of product demos and brings in feedback at the right time of the development process.

2. Wire-framing tool

Wire-framing or mockup tools let you draw pictures of software screens in a quick and dirty way. They are essential to get a quick version of the software that can be used to communicate features, test if they meet the requirement and also check if users can use them. Usually the design team within a software group uses it to get the Ux done and rest of the group just uses the output for their work. But if a stakeholder can use the tool then she can quickly draw up her own screens or make modifications to the exiting ones without waiting for a designer to do it. This speeds up the whole communications channel and makes it really easy for complex ideas to be fleshed out.

I remember one project that we picked up midway where the founder would painstakingly write up huge documents to describe features that he and his team wanted to be built. These documents would take several meetings to be explained properly and even then misunderstood by a few in the team. Inevitably this created a lot of friction. We introduced a simple wire-framing tool to the founder's team and almost magically the whole process transformed to something that was simple and fun. 

My favorite tool is, of course, balsamiq which is just perfect for non-technical people. But there are many others out there although some can be quite daunting :)

 3. Build and deployment tool

A build system lets anyone create a build of the software from the latest code and deploy it on a "staging" where it can tried out. This has to be setup by the technical team and every self respecting software team should have one setup for even the smallest of software projects.

Once it's setup, it's relatively easy for a non-technical user to learn how to "get a build" done. Usually a few button clicks in the right places does the trick. But this gives immense power to the stakeholder as it lets her get a view of the software at any time without a lengthy process involving the technical team. Essential for quick feedbacks or a sneak peek or even a pre-launch demo to prospective customers.

Many tools out there for this. Jenkins and Cruise Control are popular ones and very simple to use once setup, but there are others that are equally good. 

4. Performance monitoring tools

There are many tools that can test the performance of a software. These are essential for quality assurance team to test the software but are equally useful to a non-technical founder to gauge the quality of the software that is being delivered. These tools can give the stakeholders a list of issues that they can then prioritize and push for fixes from the development team.

The tool(s) to use depends on the nature of the application being built. Usually a few google searches land you to the right pages, but here are some that have proved the test of time. An old but faithful tool for testing the quality and performance of any web application is ySlow it gives you a nice list of things that needs fixings to make the site faster and also points out glaring mistakes which may not be so glaring at all to a non-techie. Other examples in this genre are Google PageSpeed, WebPageTest, Page Analyzer and the full of bells and whistle GTMetrix.

Great tool to keep your dev team on their toes :)

5. Code quality tester tools

Now I'm in contentious territory! These tools analyzes the actual code and rates it for quality. It identifies obvious mistakes, not so obvious bad practices even performance flaws in the algorithm. A non-technical founder may find it impossible to judge the quality of the code himself but he can utilize these tools get an idea about the code. In many ways these tools can act like auditors for him.

Again this requires technical team to set things up properly. But once done the actual analysis is a simple process. It is definitely worth the time investment. At the bare minimum a non-technical founder should insist on having such tools installed on the development environment and ask the team to use them.

Once again, many providers, but only a few that are outstanding. The tool to use also depends on the technology platform e.g. in the Microsoft world Resharper or FxCop are very good tools. Java world has many (as usual) e.g. findbugs, PMD, etc. Whatever the platform there's a code analysis tool that is just a google search away!

// This article is a reprint from our CTO's LinkedIn pulse 

Reality of an augmented future

Augmented reality (AR) software has been around for quite some time, but it wasn't until the success of Pokemon Go that it really hit mainstream attention. Now everyone is looking at ways to incorporate AR into new applications across a wide range of industries. And there are compelling reasons for this.

AR technology provides a software application advantages that were just not possible in the past and in many applications it add huge value. Here are some basics of AR from the perspectives of software product owner which we advise our customers so that they consider incorporating AR into their applications.

Why add augmented reality to your app?

The user experience offered by AR is intuitive and easy to use, which makes it appealing to a wide variety of businesses. The UI elements appear within a particular context and help the user understand how to interact with it. There are some distinct advantages that AR offers, let me try going over some with examples to illustrate my point.

With AR you get a chance to leverage real-time data to enhance your software's functionality such as tracking a user's location and displaying information about nearby store locations. You get to combine visuals with expanded sources of information, which is a powerful combination for a wide range of use cases. 

Since AR is essentially a layer over what is right in front of you, it is an opportunity to mix the online virtual experiences with the real physical. Retail stores can give in-store customers quick and easy access to the same information they could look up online. For example, they can point their camera at a product and get a full description, reviews, a usage guide and more. 

The healthcare industry uses AR in many ways, such as a solution that visualizes veins for nurses. Patients are much happier when they don't have to get stuck with several needles for a blood draw or IV.

The transportation industry guides drivers into fixing and maintaining their own vehicles by providing guided instruction that walks the user through the entire process. They can stay on top of straightforward tasks, so the only time they need to be serviced is for more complex cases. 

Widespread AR adoption is still in its early stages, so many organizations are experimenting with ways to work augmented reality into their software. These initial offerings have many exciting features with the potential to change many industries. 

Your future software development projects should consider whether AR has a place in the application you're working on. In many cases, you get a big boost to the user experience and unique features that set you apart from the competition. 

7 best practices to know about before you outsource software

Say, you have the idea for a great app or you need to get your existing app updated. You are thinking of outsourcing the development because you don't want to manage a dev team or you just don't have the bandwidth with you current team.

So you think your next step is: start looking for a team. 

No it isn't.

Because even before you start looking for a software development partner you should know about the best practices for outsourcing software. Once you know about these you'll be much better armed to start the process and move it forward. Here is a quick list of the top seven best practice that anyone considering outsourcing should be aware of.

1. Know the reason(s) why you are outsourcing

Ask yourself "Do I really need to outsource?". Once you know the exact reasons and make a list of them for future reference. This will guide you through the process and make it easy to make decisions. Make sure that your software development project is appropriate for outsourcing. You benefit the most from this process when you need specialized expertise that you don't have in-house, need extra support for the project, or don't have the time to handle it yourself. 

2. Find the partner that is the right fit for you

Find an outsourcing partner that you trust with your project. You want a company with a great reputation that's known for delivering results. Check with your peers and read through reviews to determine whether they would be a good fit for your needs. But don't just stop at that point, what may be perfect for another company may not be right for you. See if the partner's work culture fits with your one, if their working times and communications matches your preference. 

3. Cost should never be the only reason 

Look beyond price during your selection process. You may be looking into software outsourcing as a cost-efficient option for your development needs, but you need to ensure that you end up with a quality product at the end of the project. 

4. Scope out your project well

Make sure you have a detailed document of the software you want to build. If you don't have that already use that scoping work as the trial project to test a potential partner. But whatever you do, provide a detailed project scope so everyone is on the same page with expectations. Have a procedure in place for handling any additional work that falls outside of this. You don't want to have a project endlessly delayed because you keep adding features and requests. 

5. Setup strong communications channels

Put strong communications channels in place so it's easy for you to reach out to the outsourced software developers and vice versa. You don't want poor communication to make the project take longer than it should or result in something that doesn't meet your original vision. Setup multiple channels but choose one as the preferred one. So you can have slack, emails, messengers, Skype, telephone, screensharing tools even issue trackers as the place to discuss but make sure everyone knows that one of them is the first place to try. 

6. Stay involved with the project

Stay involved with the development. Outsourcing doesn't let you simply wait until the outsourcing partner finishes the work, without any input on your part. Check-in with progress, find out if they need any resources from you to complete tasks, and take ownership of this process. 

7. Use a task management tool

You must use a project management or task management system to monitor development. It doesn't matter how simple your application is or how short your project is likely to be, you have to keep track of the tasks. You can get a good sense of the pace and whether certain tasks are stalling out your outsourced partner. 

Outsourcing software development is a valuable strategy to help you get your company's needs met. But it can go wrong very easily. This list is a start, but it is essential that you know this list well so that you can find the right partner and setup a process that can maximize your chances for success with the outsourcing. Also read our tips and tricks for selecting software vendors.

I was spoilt for choice when it came to selecting the Dilbert strip for this one. Dilbert's outsourcing land is of course Elbonia and there are many communications with the Elbonians. Here is a good one that goes pretty well with message of this article.

Have you considered virtual reality for your app? You should.

VR or virtual reality may not be as fancy or "game-like" or just too far away as you think. There are many use cases where VR can be used with great success in an everyday software!

What is it?

Virtual reality enables companies to simulate environments within their software. With these applications, users can experience a real environment without physically visiting the place or they can move around within an imaginary environment. So, for example, a person from across town, in another state, or even across the globe, can experience the environment, without leaving her couch! A Star Wars fan might find herself on a Star Destroyer or a Republic Cruise ship making decisions with the help of the Force – and a VR software.

Why should I consider it? 

The use of VR can be in many facets of a software application. Many of our customers shy away from VR saying that it's just too fancy or not a good fit for their business. But if you think about it a bit more you'll find many benefits using virtual reality where you'd think none existed. Here are some example areas where we have convinced our existing or new customers to re-think their applications and to leverage this upcoming technology: 

• Cost Savings: Rather than build training room or use much needed space, companies can build virtual class rooms that simulate their new employees’ work environment.  
• Real-Life Interactive Training: Human Resources use virtual reality software to build training modules that mimic specific scenarios, and employees can interact with these modules from a convenient location. Such training often keeps learners engaged and helps to build confidence.
• Experience a User’s Pains: "Remoting" in to a user’s work environtment for specialized help. VR software enables helpdesk attendants to simulate the user’s environment and get a clearer understanding of the way in which the current issues are impacting productivity.
• Help Customers Try before Buying: Businesses can use virtual reality software to give customers a 360-degree view of products. This helps customers select the most suitable product and reduces sales returns.

So, think again, adding a VR layer might solve many of the challenges in your application or bring in a completely new way of how your software adds value to your customers. If you want our help, we'd love to share our ideas! Give us a ping at info@kaz.com.bd

How to select a software vendor?

Let's face it, selecting a software vendor is not easy. There are just too many out there and it's very much like what you feel when you are looking at many brands of vaguely similar products in the supermarket and trying to decide which one to pick up! Today, I'll try go over some of some of the things we feel that you should consider before picking up your vendor.

When you select a software vendor or software developer, you don’t just commit to a piece of compiled code. You’re committing to a way of doing business. That software – if it’s the right tool for the job – could be something you and your employees use regularly for years. And if turns out to be a square peg in a round hole, you’re SOL, back to square one, repeating the same software search you thought you just finished.

With so much riding on your selection, how the heck do you do it right? How do you find that magical software vendor, custom development team, or SaaS provider that works for you?

Evaluate the Product

Almost everybody starts their vendor search by shooting a swarm of RFPs into the void and hoping that helps narrow things down. The problem with RFPs is that nobody wants to tell you that they can’t do something. Once your RFP process weeds out the folks who aren’t ready for your jelly, you can start actually finding out what solution will work.

At this stage, you should get some hands on time with their product or, if you’re scouting custom development, their previous products. Sit through a demo, then see if you can get your hands on a trial version or run a smaller project with them first.

Pick software like you’re Goldilocks: not too slim, not too robust. You want the feature set that’s just right. Plus, you’ll see how stable their work is, and avoid critical crashes during crunch time.

Evaluate the People

You aren’t just buying a software solution, you’re getting a vendor and all the people therein. Find out what their company culture looks like. This might be the single most important factor of all. You need a vendor that shares your vision of the business landscape. Do they operate on the same time schedules that you do? If your business runs an Agile shop dropping weekly updates, imagine how much of a hassle it’d be if your vendor only updates yearly.

The people you work with should be responsive enough to take care of your issue before they cost you money. Whether that’s support issues, implementation work, or feature requests, how your vendor communicates with you can make or break a relationship. And make no mistake, this is a relationship, so chemistry matters as much in business as it does in romance.

Evaluate the Partnership

Your software vendor will become pretty integral in your business operations, so you want to make sure they operate as your partner, not just as the guy who sold you something. Are they excited about your project? If you’re looking at an implementation or custom development process, this is incredibly important. Your vendor will play midwife to your product concept, so they should care about it enough not to drop your baby.

Make sure the pricing scheme they offer works for you. That might mean exploring alternate pricing structures – fixed price, hourly with or without a cap, monthly fees, etc. It’s in both your interests to set a price that works for everybody. Your success and your vendor’s success are linked; if one of you goes out of business, the other one gets hurt as well.

Choosing a vendor should be more than just ticking off features on a checklist. You need to review the whole partnership, including the people you’ll work with and the partner you’ll have. Remember, we succeed together and fail alone.

Oh, one last thing, consider us when you are searching for developers who will build your next great app. We are a small award winning software development company solely focused on helping our clients design and build their software products. 

5 things every software development contract should have

Software projects are different from many other projects where a physical product is built. And hence there are some issues that a software development contract should address that are not very common is other contracts. Yes, like other contracts there would the usual suspects like commitments, warranties, liability, etc. But here are five not so common ones that our experience says are essential for a software contract.

1. Initiation Period

This allows both sides to disengage easily for a limited period of time after the start. This is essential because only when a project is started does it become apparent if the relationship is a workable one. A great software company with perfect skill set, gold plated credentials may turn out to be very bad at communicating ,for example. Similarly for a software company it may turn out that the client just can't agree on technology choices. Whatever it is, if there is no fit the project will fail or the process will be painful. This lack of fit becomes quite obvious very quickly. So the contract needs to take this risk into account.

Here is clause we commonly have in our contracts to cover for this initial period:

"The Parties agree that they shall commence the engagement with an initiation phase of six calendar weeks, commencing on the Effective Date of December 1, 3001. Acme inc. will provide services during the initiation phase, and BigShot inc. shall be liable for payment for such services. During the initiation phase, this agreement may be terminated with one calendar week’s notice; at the end of the initiation phase, the agreement shall enter into ..."

2. Change Requests

A software product is a moving target. You can have the world's best specification when you start but you'll end up with a software that is slightly different when you finish. This is normal. This is the way it should be. Because as the software interfaces are being built new requirements arise or old requirements change or die out. If development stays rigid and doesn't listen to these change requests the resulting software will not be good. So "embrace change" is the way to go. But, how do you setup a contract to cover this risk?

There is no single answer that fits all size. How you address this in the contract depends very much on the project. If the specification, for a project, is very good and detailed a wording that allows a certain percentage of change may work nice.  Here is an example:

... up to and including between 5 and 10% changes in any Work Product, order, and other goods and services that Acme inc. produces or designs under this Agreement at no additional cost... 

If the spec is not that clear then the above wording would be disastrous! Here is an example that just might work in those cases (this is what we have used in some projects):

 "...If the proposed change will, in the Developer's reasonable opinion, require a delay in the delivery of the Software or result in additional expense, then the Customer and the Developer shall confer to first determine whether the request is a Change Request or an Additional Feature Request. Where it is agreed that the request is a Change Request, the Customer may in that case elect to either
(a)    Withdraw its proposed change, or
(b)    Require the Developer to deliver the Software with the proposed change, subject to the delay or additional expense or both..."

3.  Software IP

This is an obvious one. So I won't spend time on this, but just mention something that sometimes is missed or not considered. In many projects the software developer might use a library or a component that it has built as a re-usable tool to be used over and over on client projects. The IP for such components belong to the developer but the contract wording should allow the customer to use it royalty free. Here is template that works nicely:

"...To the extent that developer uses any developer IP when providing Work Product for customer under this Agreement, developer grants customer a perpetual, irrevocable, royalty-free, non-exclusive license to perform, display, use, reproduce, modify, and adapt the developer IP, in any medium or form of communication now existing or hereafter developed, within the Work Product..."

4. Non-Competition

An inherent risk of employing a software development company to develop software is that they might also be hired in the future by a competitor or even worse make the software themselves. The contract needs to address this risk clearly with a non-competition wording somewhere. Here is an example:

 "..for a period of x years after the termination of this contract the developer shall not develop, reproduce, promote, distribute, market, license or sell any product or service that competes directly with the Work Product provided to customer, nor shall the developer enable any third party to compete directly with customer..."

5. Hiring Resources

The team that builds the software becomes experts of the system. If the software project becomes very successful the customer may want to retain certain members of the team. The software development company would obviously be worried about this. So this need to be clarified right from the beginning in the contract. Software resources are precious, so this is a delicate situation and finding the right balance is difficult. Here is a wording that is pretty fair:

"...customer may request developer to place named team members as direct customer employees, with the express prior written consent of developer. Developer shall be entitled to compensation for placement of such employees; the relevant compensation shall be discussed and agreed prior to any discussion of such placement with the employees concerned..." 

Disclaimer: I am not a lawyer. You should always seek professional legal advice when you are setting up a contract. 

As usual, I'll finish with a stolen cartoon from Dilbert. But to give something small back, have you read Scott's book "How to Fail at Almost Everything and Still Win Big: Kind of the Story of My Life"? If you haven't you should. Really good stuff. 

From idea to awesome - beginners guide to launching your app

Software development is a journey. Starting from an idea to a fully functioning product takes a lot of work. Involving a hand full of expertise, product development goes through phases in order for finished goods. It can be frustrating from time to time dealing with the stages of production, but a fun way to go through it is treat is a path full of challenges. Similar to those games where reaching the next levels provides a reward. Working with designers, programmers, software testers, etc. can also be educational to learn new buzz words, viewpoints, thinking. So here is how it goes:

Idea

Every software product starts with an idea, that can either be absent from the market or more to an existing solution. But the “IDEA” is the start for this journey.

You come to software developers like us  with an idea for a product that does not exist in the market. You typically speak to a "requirement analyst" (buzz word for anyone who understands software products well). You explain the features and the advantages of the product.

Sketches and features

From the discussion, we make notes of the functionality and make sketches of the product. We use the sketches to make a list of features for the product.

Wireframes

We then develop a wireframe for the product that details the functionality of the product. Wireframes are nothing but a slightly better set of sketches where you can follow how your app will behave. The wireframe pictures go through a lot of to and fro where you say "nah, I am not sure that's how I want it" and us saying "but if you don't make that action button large people will not tap it" etc.

Mockups

Once the we are all happy with the wireframes our designers turn the wireframes  into colored pictures of what the actual application will look like.  Designing mockups will help to visualize the outcome of the product, that will involve the colors, icons, identifying the different functional changes.

Development

Using the wireframes and the mockups, the programmers come in to play, the development phase starts.

Testing

Software testing will improve the product, fixes bugs and helps to do more before the release.

Launch

After all of these, when the product is ready, it will be launched to your end users.

Awesome!

Ending with customer(s) appreciating an awesome solution that they have been waiting for.
 
Now is this a brief explanation for the phases for a software development process. There are more to it when it comes to real life production process. Just try to think of it in a fun and simple way to deal with, makes the whole production process a lot easier, collaborative and efficient.

Saving the startup from burning up

The Problem

The biggest worry for any software startup owner is

Will I burn up my funds before I can get my products launched?

And this should, indeed, be her biggest worry. Great ideas are good, but if you cannot launch and get users, great ideas die out badly. It is absolutely essential to get something out quickly, get user feedback and pivot to the next step. If you can't then there is a very good chance that your startup will just "burn up".

A great article is around expected burn rates (in US) and what you should aim for is Burn rates: How much? by Fred Wilson. Here is a rule of thumb about burn rates from there:

...multiply the number of people on the team by $10k to get the monthly burn. That is not the number you pay an employee. That is the "fully burdended" cost of a person including rent and other related costs. 

And this was 2011. The figures are much higher these days for sure.

A Solution

A great solution to this burn up before launch problem is to use a development partner who can lower the costs of production. By having developers in low cost countries such as Bangladesh, Cambodia, Nepal, etc. it is possible to lower the costs without compromising on quality.

We are old hands in this start up and burn up drama. When we started in 2004 our first project was to help a silicon valley start up save themselves by finishing and launching a product they have been trying to build before they ran out of money. We made their remaining funds run a long way and got the product out within 6 months within budget. With that as our initiation, it is no wonder that we have helped more than 20 startups get their products out on their angel funding. Once the 1.0 product is out a start up can breath easy and see how user adoption and feedback is. Based on that they can decide to seek more funding or in the happy cases start making money!

For us, as a software company that thrives on ideas and innovation, working with the startups is the biggest fun. This gives us the chance to work on new technology, challenge ourselves with difficult technical hurdles and deadlines. 

We are so confident on getting the first versions out with angel funded startups that we are offering startups looking for dev partners in the CeBIT 2016  a "Launch under 10K Euro" offer. 

Interested? 

Meet us at CeBIT2016 or contact us to explore.

Learn More

Launch under 10K

Two ingredient recipe for a great software team

Great software teams are hard to define, yet they are very easy to recognize when you see one. There is energy, enthusiasm, excitement and everyone in such a team feels like they are on a mission. Things just get done and software launches feel robust and predictable.

Great, I need a dozen, but how do I create one?

Now that's a really hard question. We've spent a long time building software products and the teams behind them. And have managed to create a reputation for building great teams. So we get asked this question a lot. After answering numerous times at different levels of hand waviness we have come to realize that we can boil it all down to just a single a basic recipe with just two ingredients:

1. Gelling - how close the team members feel to each other and how strong they feel for the whole group.

2. Openness - how easy is it for team members to criticize each other or themselves or voice concerns without worrying about propriety.

The funny things about our recipe is the the exact measures of these ingredients don't matter. The more you have the better things will be!

There are many things you can do to get these ingredients into your team. You will need to experiment and see what works for your team. If you asked us to name just one thing that works (for us), we'd say it must be our: 

Team events

We arrange events where some kind of group activity is needed. I think it's essential for these events not to have the explicit feeling that it's a "corporate team building" event - that feeling makes the gelling less natural. We try to make the events fun but include some elements that necessitates the group's input.

A classic at Kaz is our yearly trip where the overall planning is left to the team to finalize. This gives the team to come together and work together to create fun for the entire team as well as their families (as families are welcome too in these trips). We intentionally leave some constraints, a shoestring budget is typically the a big one but also there could be others like "ensure that the kids are not bored". These restrictions make the team members think in terms of the whole team which is a big thing for gelling. 

Good luck with your team building efforts, but before leaving, here are some pictures from our recent trip to Nepal!

How to test a new outsourcing partner?

In the world of software development projects there are many ifs, buts and maybes. It's hard to find absolutes. It's next to impossible to give a formula for success. But I think at least the answer to the question "how should I test a new outsourcing partner?" is one of the rare cases where you can confidently say you know the absolute correct answer! It is equivocally:

Start with a small test project or a prototype building phase.

Here are some examples of this small project that we, at Kaz Software, have suggested, to our clients, to test us out!

• A test project - made up just like a test to try the new partners out. Ideally you should know what outcome you'd like so that you can judge (just like an exam) the result. Even consider doing this test internally with your team too, so that you can compare. 
• A tool that you needed built - this may be something thing you always needed but could never spare enough dev time with your team to do it. Say for example - a tool that helps HR generate some monthly reports. The tool should have some challenges that you want to check how the new team solves. Nice thing with a tool is that you probably will get a useful tool out of this testing period.
• A prototype - this is a really good approach for start-ups. Get the team to build a quick-n-dirty prototype of the actual application that you want them to build (at least a subset of it that is). This has the added benefit that you can judge how much they captured your specs and also lets you use the prototype for demos and future spec clarifications. And if you continue with that team the domain knowledge already picked up is really a big thing.
• Product design/ideation/brainstorming - this is probably the easiest one to try if you don't have the time for a more elaborate one. This should, at a minimum, be a week of meetings with project leads, designers and even developers just brainstorming what you want to build. Coming up with new features. Output should be at least wireframes of major use cases. Although it doesn't let you test coding skills, it lets you see how pro-active the team is and definitely lets you check out their culture. And the output itself is useful (hopefully).

Do you know which one you will like before trying it out? Only if society would allow a nibble before a committed pick? :( 

The gist of the problem is very similar to the problem you face when you have to choose a chocolate from a  new box. They all look pretty good, but until you try them out you don't know for sure that you'll like what you've picked. Sadly it's socially quite unacceptable to nibble a chocolate first and pick it up only if you like the first nibble. But happily this is very much a possibility in the world of software outsourcing!  

You can stop reading here. You don't need to know why doing a small project is the correct answer - I'm that sure about this bit! And we have a lot of experience here, working on outsourced projects from all over the world for the past twelve years! 

But if you are interested here are some explanations.

Lets you check for fit with a small cost.

When you embark on a software project with an external team you just don't know if there is a good fit between your team and theirs. Do they understand what you say (even if they speak the same language)? Do they prioritize the way you do? Does their culture fit with yours? Does your team like their culture? Do they use the tools that you want them to use? Do they use them the way you expect them?

Endless questions which can never be answered satisfactorily without working together. Yet these questions are vitally important for the end product. Fit is everything. Let me say it again, the single most important thing for a successful outsourced software project is fit. But you only learn about the exact nature of the fit deeper down in an engagement. When it may be too late to exit if you suddenly realize there is not enough fit.

Lets you extrapolate

The results of a small project lets you extrapolate and make projection of what the result of the real (bigger) project will be. The way a team manages a small project is in essence the same as the way it will manage a bigger one. If the culture is "get it done" or "analysis paralysis" or worse "random walk" you spot it right away - and you can be sure that the same will apply to your real project.

With the results of the small test project you can make much better informed decision about a outsourcing partner and then decide to commit or not to commit.

Lets you exit early if you need to

Obviously. And exiting early is very important when you know something will not work and you need to start from the beginning to find a new partner. Ideally you should have the backup candidate ready, or even better, if you can afford it, make them do the small project in parallel - which is what I'm calling A/B testing loaning the word from webpage optimization.  

Lets you run A/B testing 

If you can afford it, get competing partners to do the same project in parallel (without telling them you are doing it!). This then let's you compare the result and find the better candidate.

Another variation is to get your internal team to do it in parallel and see how your own is different from the  new partner. If you do this, consider doing a presentation/retrospective session where the external provider explains their decisions to your team and check how the debates go between teams where their solutions differ. Very useful to find how the teams will work together (and separately your own secret review of your team's performance thrown in for free). 

Lets you fix issues either for this team or for your next one

There will always be some issues that need fixing when you are going to work with an external software team. The test phase lets you identify them right away, so that you can have that as a to-do list when you start working on the real thing. 

Even if you don't eventually decide not to go with the team, this list tells you what to watch out for when you look for when you go back to selecting another partner.

OK, here is my find from Dilbert today. Btw, if you don't like Dilbert strip then maybe there would be a fit issue with us! But if you do like them and you have a software project that you want to get done by the experts (and want it done at a lower cost), give us a knock - even better give us a test project! We may even do the test project for free to show off our prowess :)

Back from my shameless self promotion here is the Dilbert that I promised!

Be careful techies, I'm Dutch!

How should Dutch software project leads manage and run their outsourced software development?

This was a question that came up when we published our recent article about how Dutch software project leads are different than others (and why those differences are good). In today's article I will try answering that question based on our experience in working in software projects from the Netherlands for more than a decade. 

Warn that you are Dutch (and you are direct)!

There is no denying it, you are likely to be perceived as difficult (or at best: different) when you use your natural directness. This perception can make things go wrong, and lead members of your offshore team start to think your sentiments as always negative. Software is all about collaboration and a perception like this will make collaborative work hard and result in a bad software.

Testimonial for Kaz Software from International Guidelines - an Amsterdam based software startup.

As I argued in that other article, this directness is really your asset in a software project - so don't even think about changing (or "adapting" as some people may say, stretching the agile philosophy too much). To address the risk of a negative perception all you have to do is remind your team at the beginning (and then time to time) that you are Dutch and the Dutch are known to be direct - they don't usually mince words. You will find that your software team actually appreciates this directness - once they understand that this is how you are from a cultural context. Any good software team understands very well the need for constructive criticism of their work. And once the fear of negative emotion is gone it will make things simple. It has always been that way with all of our projects.  

Beware of deadly high PDI

PDI is power distance index. Which, in the context of software development, can be explained as a measure of:

How unlikely is a junior programmer to tell a senior team member when he spots an obvious error in the latter's code?

High PDI means team members stay silent and don't speak up their concerns. PDI varies by nations. And it has been shown (and you really don't need data for this, you can feel it) that countries in South and South East Asia have high PDI. Which translates to the fact that your developers are less likely to speak out against you even if they know you are wrong. Check out our article about the risk of PDI in software projects.

This becomes an acute issue when you mix a Dutch person as the project lead/owner/client and an outsourcing team in a high PDI country. The Dutch person speaks out with directness that is her natural instinct, the high PDI "stricken" developers start to take her words as the law - so there is no debate, no arguments. A software cannot be made without debate (and we say even fights) - and the situation above removes those essential debates leading to bad design, bad technical decisions and thus bad software.

So what can you do? Difficult to answer this. You can of course hire a company who has a culture of speaking out (and thus low PDI), for example us (ahem!). Kaz Software does a lot of things to keep the PDI low (check out our article about this: Killing PDI ), and so does many other companies who recognize this threat. The other option is to create this awareness yourself within the team, particularly the team lead or the interface person. If the external team lead understands this she can then mitigate the risk within the team.

Insist on visibility of day to day workflows

This is important in any outsourced software project, but particularly so if you are Dutch. This visibility will give you data to act on, take corrective steps on a much granular level. This would reduce a lot of friction that are likely to happen if you see results after long periods.

Insist on making the task management/issue tracker available to you online. You should be a user in the system and be able to add/modify/comment just like any other team members.

There must be (as with any project) a build system that lets you build and use the software at its current state. A dev and a QA server should let you see and use the software at any time. And you should set aside dedicated time to play with the software regularly (ideally daily) and give feedback on what you see. This is a basic agile step, but also an important step to prevent friction.

If you have software people on your side, the code repository should be regularly used to compile the application being built independent of the build system that the dev team has. This will let you identify technical issues early in the process. 

A weekly call is a must for any software project, but consider daily calls too if you can keep them short (otherwise they become detrimental to the workflow).

Break the ice

I've saved the easiest and the best for the last. Most of the time all you have to do is just create a good relationship with the team. If you can break the ice, everything else becomes that much easier to do.

If your budget permits visit the team, do some activity away from work together. Even a trip to the local food street and just hanging out with the team will do wonders. If a trip out is not possible then consider doing a video conference together with team and make it a non-work thing. It could be a simple introductions and sharing of stories. Tell a funny story, joke a bit and the rest becomes easy.

Distance makes human relationships seem rigid and artificial. Add to that the cultural difference and your infamous directness, things can seem very non-human-like. Break the ice, humanize the endeavor and you'll see that things are much simpler than it seems.

Before I leave: we are doing an ebook: "Guide to happy software outsourcing" where we will summarize all the little tips that we have been writing about. Leave your email address with us and we will email you when it's ready.

5 things software entrepreneurs must remember

Having a great software idea in your head and a fast moving software team to make that idea a reality is what it must be like to be on drugs. It’s addictive, it makes you stay high and there is nothing in this world that you can quite see with pessimism. This is what makes software entrepreneurship so attractive, this is what makes thousands maybe even millions give up their jobs and jump into this unknown, knowing all the risks and odds.

But beyond all the known risks there is an enemy that is always lurking– and very few people recognize it. If not recognized this enemy can kill.

The enemy is within. It is your enthusiasm! Yes, the very thing that makes the start-up successful, the experience amazing and that fosters innovation can also if not kept in check destroy everything.

Kaz, as a software development consultancy, that works with early stage start-ups and their highly driven owners and leaders, we’ve seen that enemy many times. And we have helped our clients tame this enemy and use it in right direction for the right causes.

Today I will list the top 5 reminders we give to our clients - to keep that enemy in control.

1. Remember that the app will solve only one thing.

In the mind of the owner the original idea of the software evolves and starts to become something that can solve anything. Maybe it can, but time and money both are limited. And the urge to add yet another feature to cover yet another use case can derail the software building process and eventually delay things enough to make the app fail.

The only way to keep things in control is to remember that however great the app, it will probably solve only one human pain – that is the most important use case and everything else can be discarded. The focus should be only that single use case, and release with that use case.

We sometimes suggest our clients to have the use case put into a single sentence, print it out and paste it in front of them somewhere visible.

2. Remember to compromise

A piece of software is all about compromise. You have to compromise on features, bugs that need to be fixed, delays you have to accept – the list is endless. By knowing when to compromise and on what, you make development process smooth and meet the deadlines. And most importantly for early stage startups get the release up where people can start using it.

For entrepreneurs, their idea and thus the software is like their own child. This makes it very difficult to compromise. In some cases, we’ve found, they forget that it is good to compromise. They start treating compromise as something evil. And this has huge negative impact on delivery schedules.

Remembering to compromise is something that makes the difference between a software out on production box and a software in an endless loop of fine-tuning in the dev box.

 3. Remember to trust others

Software requires collaboration. A single person cannot get everything done to get a software from ideas to reality. And collaboration implicitly requires trust.

Normally a software group can easily create trust amongst its members (obviously things can go wrong, but that’s because of some real problem in the team). But in a start-up scenario, especially in its early stages, sometimes the owner can find it difficult to form that trust relationship with her developers. The cause, I think, is because of the constant feedback she gets from the team about the time it might take get certain cherished features done, etc. As harbinger of bad news, typically the team lead may seem to be the person who always dampens the spirit. This can sometimes make the owners difficult to trust the lead or the team. And if that happens everything suffers.

Teaching herself to trust can be one of the best things that an entrepreneur can do to help the team. When we face circumstances like this, we try communicating this in various ways. Not being Dutch and not having the wonderful ability to say things directly makes it difficult for us! But our way out is to do it in little steps and also to involve the owner more with the actual development process so that she can understand things better.

4. Remember that the software is for others.

This one is the hardest to remember. The entrepreneur lives with the idea and process of software building with such focus that, we find sometimes, she forgets that the software she is building is actually for someone else – users! Remembering this important, knowing what your first customers are like and that the fact they might have completely different persona and requirements than you keeps the feature planning and decisions on track. What you may value as important may not be what your average users would value so much.

We suggest doing a regular thought exercise where a question starts with “When user Mr. X uses this feature…” to our customers. This sets the context and understanding that the software need to be viewed through the eyes of a typical users. Our interaction designers are big on Alan Cooper’s user persona creation process and we have found that including the owner with that process helps immensely to disassociate herself from the target software users.

5. Remember that there is a tomorrow.

Owners sometime forget that software has the possibility of versions. What we cannot achieve in this version can easily be added to the next version. Splitting up the features into versions and phases is the essential software project management activity.

Sometimes it’s hard to push cherished features in the back-log, and owners feel like that they have to cram everything in the next release. If the next release is the first one, this is most painfully felt. Remembering that there is a tomorrow that a new release can be done pretty soon – even really the next day can help a lot.

Are Dutch companies difficult to work with?

We sometimes get asked the question: "are Dutch companies difficult to work with?". We get asked probably because we have been working with companies in the Netherlands for more than a decade. There seems to be a perception (at least among software consultancies)  that they are "difficult" and I think I know why that perception exist. I'm going to argue today that the qualities that create that perception are exactly the qualities that every outsourcing software project owner should have to make that project a success. 

But first a disclaimer: it is always risky to generalize, and I'm no world expert on how the techies of a nation think (does that make me safe from some of those eggs and tomatoes ready to be thrown at me?). 

Here are the qualities that I find common in Dutch software project leadership:

Persistent concern for the state of the project

The project managers or the owners have an almost palpable feeling of concern that the project might be going in the wrong direction. This keeps them pinging back for regular status checks, keeps tech teams on their toes and there is usually a lot of communication. 

I think this is the single most important thing that EVERY software project owner should have, irrespective of the fact its an external team or an in-house team that is working on the project. If the team is external, and especially if the team is thousands of miles away this is probably the factor between a project that is failing and one that is successful. But note that this sometimes this might create an impression in the tech team that the leadership cannot fully trust their ability - so this has to managed well to keep the team productive.

No mincing of words- the directness

Dutch project leads don't shy away from saying negative things if they see it. Whereas in other cultures (including Bangladeshi, but most painfully in the English) there is a tendency to keep negative things unsaid. Not so with the Dutch, and this is just perfect in the context of software projects. You just cannot stay polite and hope that those bugs or those obvious missteps in the dev process will fix themselves. 

At Kaz this is something we try to code into our genes (check out the article about this: killing the deadly PDI) - to be direct, to say the negatives without worrying about how your colleagues would feel because this is the only way to make great software. It's incredibly lucky that with the Dutch project this valuable trait comes automatically.

Budget consciousness

Although it is obvious that every project leadership should be conscious about the budget, you'd be surprised how many stories there are about projects eating up the complete budget because the stakeholders get carried away with features or they just don't plan things well. Software projects are prone to go off track - estimates tend to be wrong, features tends to bloat, owners  love to get fixated about some use case that they must have yet no one uses.

Being budget conscious keeps the project on track. It lets everyone make informed decisions about where to compromise, what feature to prioritize and most importantly when to  stop. So having this in project leadership makes projects successful.

The proof of the pudding is in the eating as they say, and I can tell from Kaz Software's experience in working on Dutch software projects for the last eleven years that whatever it is, the Dutch certainly have a flair for successful software. We are proud to say that we've never had a project from the Netherlands that had failed!

Meet us.

We'll be in the Netherlands

22-26 November, 2016

If you are around and want us to meet you, to discuss a software project, please drop your email address below. 

---

Update: One of our customers in the Netherlands recently did a video about our work with them. Thought this is a perfect place to share that.

Nightmare in code street - a software project horror story with a happy ending

I recently came across a documentary, spaghetti code, that talks about how a multi-million Euro software outsourcing project became a disaster. The film was in Dutch but given the topic, which is the focus of most of my energy these days at work, I persevered to understand. And with the help of my Dutch friends got to the gist of the story, which is sadly a very common one – big company outsources software development to another big outsourcing company, there are many layers of management and not everyone is sure what is being done, the project fails and developers far away gets an unfair proportion of the blame (although to be fair, the documentary blames the management too and also there additional twists of greed and corruption).

I smiled and then raved a bit with righteous rage (being a techie in the inside meant the slur of “spaghetti code” and blaming it all on the developers touches a nerve or two). Then I cooled down and decided to write my “ultimate guide to safer outsourcing” or something along those lines. Which, by the way, is what I was planning anyway for my series on software project outsourcing – the first of which appeared last week: deciding whether to outsource or not? But a little more reflection led me to ask:

 Was I also not hiding behind righteous indignation and the comfort of the “blame them” myself? Weren’t there a story or two of my own where things went wrong?

Let’s face the facts; a software project is difficult to pull off smoothly even if the team is in-house. Add to that difficulty a team that is miles (sometimes thousands of miles) away, different culture, different language and different time-zone – you have a really risky venture. There are of course ways of managing that risk. They are time honored, field tested and pretty fool-proof – but they are to be the subject of a different article soon. Today, I’m going to face my nightmare and tell you the story of how everything went wrong in one of our projects, and (happily) how we survived and saved that project. I can’t go into too much details, of course, but will stick more to an overview and on what we learnt from the experience which I think will be of more value to my readers.

The project

It was an angel funded project trying out a very innovative solution for a common problem that happens in large companies. There were three people on the client’s side with none of them with any prior experience in software. They had an existing codebase – a left over from a different company that they had used and did not like.

The spec

We received a large amount of documents at varying degrees of up-to-dateness (and yes, that is an acceptable noun). Then we did several sessions of going through the concepts. We found that the clients have actually moved away from many of the features as described in the specs. This is something very common with start-up, actually it was surprising that they had specs at all, so we were not worried.

The process

We are an agile shop when it comes to process. For startups we choose a Kanban model, where pretty much everything thing can change at the last minute (within reason). This works best for start-ups because most of their priorities and product requirements move with time.

We chose trello for issue management, google docs for sharing documents, github for source control. We put a tried and tested scheme of weekly meetings and daily builds. Since we saw a lot of instability in the feature requirements, we added a short but daily feature discussion session with the clients and our designer and  project manager.

The nightmare

Almost from the start things started going wrong. We kept getting feedback that the product features were not what they were expected to be, this led to piling up of tasks that were adjustments to features we’ve already done. This backlog led to delays in delivery of major releases planned – which led to our clients losing important business. Something was very wrong, but we didn’t know what it was. We had put in all our standard safety measures in. We were communicating (maybe too much) on a daily basis. It just didn’t make sense.

The realization

After several missed deadlines and lost weekends (which we avoid the like the plague because it’s the worst thing you can do the developers’ productivity) we decided we need a proper retrospective. We pinned the problem down to the following:

1.       Clients could not visualize the features that were to be built based solely on the wireframes we were using. We had opted to do quick wireframes to speed up the process to meet the delivery schedules of the client (typical for start-ups that need to demo to prospective investors).

2.       The feature priority that the clients were setting was not taking into consideration the relative level of effort for the features. So we were not doing the good practice of picking up easy to do features first even though they might be slightly lower in priority than other harder features.

3.       Unrealistic expectation about deliveries, and correspondingly ambitious estimates from the team trying to appease those expectations.

The happy ending

We spent days thinking up of new and quite frankly convoluted fixes. But finally we boiled them all down to an absurdly simple solution – there needs to be a techie on our client’s side.

We managed to convince our clients (somehow, don’t ask me how!). They hired a consultant who would work with them 3 days a week in a role of a product manager. And things changed for the better almost immediately. The fix really felt like a miracle cure.

The moral of the story

… is that: there is no single formula for making your outsourced software project safe from disasters. There are prescribed best practices that you must follow, but stay alert for signs of failures and jump in with remedies when you see them.

Well that’s the horror story. You can never really depend upon a foolproof process in this world. But there is one thing you can certainly depend upon – there will always be an appropriate dilbert strip that you can steal, for anything to do with life in engineering. Here is my loot for today’s article.

5 points for deciding to outsource or not your app development

You have an idea for a great software or an absolute need to get an app done to boost your productivity, but you don’t have software developers. How do you make your app? Do you hire developers or outsource it to a bespoke software development company?

These questions are not easy to answer. From our experience in this space for more than a decade, here are the top 5 things to consider.

DO I HAVE THE DOUGH?

Do you have enough money to hire in-house developers and also spend on marketing?

If the answer is yes then it’s a strong reason not to outsource. We’ve got to be honest here, having your own developers working next to you is the best, if you can cover some of the other risks around this. But you should also consider, if it makes sense to get more mileage out of your funds by using a lower cost source or if you want to spend more on marketing, keeping the development cost in control.

CAN I MANAGE TECHIES?

Do you or your in-house team have experience managing a technical team?

If you answer yes then that’s perfect and you will need that experience whether you outsource or hire internally. But if you answer no, then that is a big reason for outsourcing your project. As anyone with experience in the software world will tell you, software project management is a pain (and also an art). With an outsourced project, if you choose the right partner, you can also outsource that pain to someone else! Set the milestones and your delivery expectations, reasonably, and it’s the job of an experienced project manager to get those expectation met.

HOW SPECIAL IS MY CONTRAPTION?

Is some unique algorithm or convoluted calculation the main business value of your application?

If you answer yes then this is a strong reason not to outsource, at least that part of the software which is unique. When you outsource you don’t have direct control over the resources and a developer who might have the whole algorithm figured out in her head might just leave and it’s very difficult for you to stop that. Also, business sense says that the knowledge should stay in your control. Google wouldn't be google if they outsourced their search logic!

The solution could be that you hire developers for the core and save money by outsourcing the the rest. Or you could have a contract which lets you have the option of hiring the resources at some point.  Here is something that we sometimes have in our contract to cover this situation:

“...Acme inc. may request Kaz Software to place named team members as direct Acme inc. employees, with the express prior written consent of Kaz Software...”

CAN I GET ALL THE SKILLS TOGETHER?

Does your in-house team have a variety of technical skills?

Software requires all sorts of skills. To start things off you need a variety of ideas in your brainstorming so that innovation can happen. Then you need designers to draw things. You need technical people to say what’s possible, what’s a good trade-off (“oh that will take years to support on Internet Explorer”) and you need them to write the code (of course!). Then you need testers to check if there are bugs and systems guys to find the right server to deploy and launch the product.

When you are using an in-house team, usually you have to get by making the same person to put on multiple hats. This may work but it limits the set of ideas and possibilities. When you outsource, you usually get a pool of resources from which people can be drawn into your team at the right time and then moved out. This is a big one for going the outsourcing route if your local team is small or non-existent.

HOW ROCKY IS THE ROAD AHEAD?

If you have a business plan and the market research that says things should be a sure shot then going in-house works. But if you are not sure and know that the road might be rocky ahead then having development outsourced is much safer - it lets you ramp up or ramp down fast. With an in-house team both growing and reducing fast is painful and expensive. And having a reputation of that instability makes it that much difficult to hire talented techies from the market.  

Worried? Don't be. At the end it's an adventure and if you play thing right a really good one. Contact us if you need our advice or want to consider us for developing your app. We have loads of experience helping customers like you. 

Contact us for free advice

Contact us for free advice

The Internet of Things Food For Thought

Jacob loved to spoil himself every Friday with a visit to the local steakhouse. After a hard weeks work what could really be better? He would order the fillet mignion with a side of mushrooms and wait for the steak to arrive, his mouth watering at the thought of cutting into the thick juicy slab of burnt meat and tasting the juices come out as he chewed each mouthful. The aroma and flavors assaulting his senses would send him into a reverie. But today was a little different, as he was toying with his salad it suddenly dawned on him that he never really thought about how all this food really reached him here at his favorite restaurant. Where did it come from? How was it grown? What really went behind the scenes to get him his wonderful steak?

Most of us really do not give a second thought to the way we consume our food. Yet with the world population set to hit 9.6 billion by 2050 governments and farmer are hard pressed to get productivity up and costs down to ensure that the next 2 billion people are fed. Already climate change and the environmental impact of current farming practices are creating stresses that seem increasingly insurmountable given that lack of agricultural land has already pushed farming to the very fringes of what we would consider cultivatable land. Compound that with water crisis’ affecting more regions of the world than ever before and burgeoning urban population demanding more and varied food, we have the makings of a perfect manmade disaster unfolding on a global scale. Leaving us to ponder whether our children and grandchildren will have access to a nutritious diet.

What can be done? 

The key to increasing productivity in agriculture lies in our ability to reduce waste and increase efficiencies of all inputs while at the same time scaling these up in food supply chain as well. How? Technology using the Internet of Things (IoT).

Imagine a Smart Farm completely IoT enabled with sensors built in all the equipment. Fields with an array of sensors connected to the cloud and software to help make sense of all the data. Now Farmers will have the knowledge to control the amount water or fertilizer to use when to use it , to see pest infestations before they become problematic, to sense stress in their crop days before it becomes visually evident, and to know exactly the best time to harvest their crops. Farmers could benefit from knowing what crops to plant by using plans based on predictive algorithms showing tentative weather conditions and market situations.  Similarly grain storage silo management can become more efficient at monitoring the right temperatures warning of impending equipment failure keeping food at the optimal quality. Just in time (JIT) deliveries of food could become very efficient keeping it fresh lowering the need for extensive refrigeration and chemical preservatives. Food processing companies could now directly look into their supplier’s quality using software that tracks food quality even as the food is grown in the fields’ right up to the supplier’s storage and shipping points. 

What is happening?

Already we find drone software being designed to analyze geospatial and image data for farmers. Small sensor have been designed to read the water content and solar output that crops are receiving. Heavy farming equipment is not far behind, with sensor being built in to harvesters that can track ripest fruit to be picked and so much more!

Companies and governments have taken notice and are gearing up to meet the challenges of an agricultural revolution that the IoT may enable. Already US$ 471 million has been invested in the first quarter of 2014 for IoT enabled devices for farming. Smart farming will allow farmers and other stakeholders to understand the diverse conditions that create variables over a period of time. Embedding intelligence into the design of equipment will allow farmers to combine all the data from different sensors into useful information that can be acted on. Even though a farmers relationships with the ecosystem of suppliers and stakeholders can potentially be very complex ranging from machine manufacturers of farming equipment and heavy farming vehicles, suppliers of the machine to machine technology and the software developers creating IT based decision support systems, over time the value of these will create synergy for all the participants allowing for more efficient and effective designs to be incorporated using the Internet of Things.

Overtime as the cost of IoT enabled farming devices declines and more knowledge is gleaned from initial experiences we’ll eventually see these small devices being employed by poor farmers in developing countries where they will make the biggest differences to the vast deprived rural populations who live with limited access to farming knowledge and technology.  

Coming back to Jacob who has just now had his fillet mignion delivered to his table by the waiter. He looks at the gorgeously seared, medium rare piece of meat on his plate; gently cuts into it and lifts a piece into his mouth enjoying the burst of flavor with the knowledge that world of the Internet of Things just may let him enjoy his hard earned weekly steak a bit longer.