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. 

The Internet of Things and Marketing to the World

You are walking around the shopping mall with your shopping list but something weird is happening. Every time you change an aisle your phone seems to come alive beeping away cheerfully! You look at the screen and see a list of products that has magically appeared all of them vying for your attention “buy me”, no “buy me” “ I am going at discount”, “Try me out for the best experience” etc. While you are wondering how these products found you out and how they know what you are looking for, you realize that the world has changed after all, and that the Internet of things (IoT) is knocking on your door.

The Internet of Things (IoT) is going to change how you experience your next shopping spree. How? Well all the objects and devices with their sensors, connected through the Internet will relay a lot of information about how you are using them, where you are using them, when are you using them. All this data will be mined by the products manufacturer and marketing companies who will compile it into information that enables them to design, contour and make improved products that are better able to meet your needs and wants. Advertisers will be able to build profiles based on your preferences and reach out to you in unique and personalized ways. They will ultimately convey messages or content that is in line with the consumer’s mindset, targeting people at optimal times and places through nontraditional media.  Sound incredulous? It is already happening as many of the products around you like your smart TV, cellphone and console are “listening” to you and gathering data on what you are doing most of the time without you even realizing what they are up to imagine what would happen when you have a home full of IoT enabled devices.

The brands we use will become our life long acquaintances as they have a continuous dialogue with us through continuous interaction. Imagine a device that reminds you to replace a worn out part or tells you a newer version is out with improved features and you might want to try it. Advertising will become in a sense crowd sourced as the creative impulses are tempered with information made available through the IoT. New models of marketing will develop that move beyond the legacy methods opening up completely unharnessed horizons for companies.

Digital Marketing will move beyond customer relationship management as the information gleaned becomes more personalized allowing customized and targeted approaches to reach consumers. E-commerce will become ever-present and pervasive in every aspect of our life; sometimes maybe even intrusive.

Making sense of the IoT is going to be challenging for marketers as the influx of devices will require them to consider context and apply methods and skills differently from traditional techniques. Turning big data into information will require advanced statistical models and software to make sense of all the information flow allowing them to create highly accurate profiles of the consumers. One of the best benefits that will come is from the unfiltered nature of the information that they can get making understanding consumer behavior just a little bit easier. Marketing will become more about excellent content, emotive appeal and more device and platform neutral as a multitude of IoT enabled devices make way in to our lives.

Remember the next time you go shopping if a carrot calls out to you saying “eat me”, or if you find the milk cartons “mooing” away, or if the latest perfume says “smell me” or a t-shirt calls out “I want to be all over you” don’t think that the world has gone crazy, it is only the world of the Internet of Things calling!!!

Bridging the Digital Divide with the Internet of Things

Have you ever felt that pang of anguish while visiting a friend’s house when he proudly displays his new 80 inch OLED smart TV connected to his 1 Gbps connection, which is in turn connected to his new iPad projecting Apple TV on screen, as he goes on lecturing about the benefits of the latest tech? You look around his room to see the latest gadgets all there; making it impossible to keep the “green eyed monster” at bay, while at the same time you fumble to your pockets to hide your 3 year old smartphone. If you have experienced something similar to this situation then you have had a small taste of the “Digital Divide”.

The reality of the Digital Divide (DD) of course is much larger, access to the highest bandwidth and latest tech can make huge differences in people’s lives.  The DD can be between men and women, rich and poor, different ethnicities, even between the developed and developing countries. The advantages that the latest tech offers simply does not percolate everywhere at the same time, creating disparities that can leave behind large segments of humankind in a kind of “digital dark age”.

Now you may kind of wonder why does this Digital Divide happen? Well there are quite a few reasons this happens let take a brief look at few of the major ones (for convenience let’s use country comparisons as these are the areas where the largest differences occur).

If you remember the example above, the friend who has bought all these gadgets seems to clearly have the cash to purchase them maybe he inherited millions or made it big, it doesn’t matter, he has enough money to get the latest stuff. This situation unfolds on a much grander scale when we compare countries. If we compare developed countries to developing countries we find great disparity between them when we start using the right metrics like internet penetration, cost per mbps, cost of capital for buying ICT stuff like computers, smartphones etc. just to mention a few, a clear yawning gap appears. So economics does play a big role in the digital divide and the unfortunate truth is that it is in the developing world, where getting the latest tech can make the most difference in alleviating poverty and creating empowerment.

The next thing is access to technical knowledge, research and development this is an area where developed countries have the complete edge. If you look at the number of patents filed in developed countries vs developing countries it will give you a good idea where the next tech is going to come from. For example if a country lacks software designers it will have to import software or buy licenses for it or if they do not have backward linking companies that produce hardware for the ICT then they will have to rely on imports again this can quickly add up to a significant portion of their foreign exchange being drained or funds being curtailed from development projects. Developing countries do not always have the infrastructure, funds, and know how (brain drain happens the most from developing countries) to cultivate and deploy the latest tech leaving large swathes of their population deprived.

 Infrastructure or lack thereof can hamper the ICT projects. If a country suffers from chronic power shortages or if a significant portion of the population lives in remote areas where there is no power grid then the power to use devices becomes more complicated and expensive. Similarly if a country cannot deploy fast fiber optic or cellular communications then information cannot disseminate properly rendering ICT projects inefficient.

So what can we do?

Simply placed we can start using the internet of things to start overcoming traditional barriers to ICT deployment. The Internet of things will open up unique ways for countries and people to enable devices to enhance their lives. As the Internet of Things comes to be and matures we can hope that companies will be able to achieve economies of scales that were previously unheard of bringing down production costs. Also the IoT can enable people to design develop and customize products for their own needs. Imagine what an ingenious student in a developing country could do with a 3D printer. IoT might enable decentralized manufacturing of customized products suitable for each countries situation. IoT enabled devices will increase efficiencies in everything that they are used in creating net saving for everyone and opening up more resources for other uses.

While we can perhaps argue about the risks of IoT deployments and maybe they will create their own set of issues as the popularity of IoT enabled devices grows, but this always happens whenever new disruptive technologies come about, leaving room for the next generation of thinker and doers to innovate something new, to solve those problems.

Getting back to our story, now maybe you have just barely managed to control the Green Eyed Monster of jealousy or maybe you have allowed it to take control and are contemplating whether selling a kidney will get you the latest must have gadgets. Then know this the Internet of things is coming and just maybe with it, the vast deprived humanity might get some parity in their lives.

Stay with us more about the IoT is on the way!!!

“May the IoT Be With You” - the Internet of Things Lets You Think Big.

OK so we’ve been hearing all the hype about the IoT. Everything around us is going to become smarter and they are going to “talk” with everything else including us. It makes you kind of wonder when you see nations, governments, large corporations, small companies’ even individuals taking serious interest in the Internet of Things about where all this is really going.

If we look at the following graphs the first from the MIT Technology Review and the Second from Gartner it will give us a clearer picture about what is really going on:

The first chart gives us pretty good idea about what is happening we can see that as we approach 2020 that growth in PCs & Laptops, Tablets and Mobile phones is tapering off near around the 16 billion mark but devices or things is shooting from about 1 billion devices in 2010 to over 12 billion in just 10 years that is a staggering 12X increase!!! The report by Gartner shows that connected PCs smartphone and tablets are actually dropping with IoT enabled devices reaching a staggering 25 billion!!! No wonder everyone wants a slice of this IoT pie because it is a growth driver where the slices are getting bigger really fast. No one can afford to miss out on this.

Miniaturization and nanotechnology are quickly allowing us to make small computers that can be placed on almost anything coupled with smaller cheaper radio chips, capable software and more efficient micro sensors the potential for diverse product design and development increases almost exponentially. Meaning we can start to place these radio enabled computers on almost everything. Who knows with more advances we might even be connected directly to each other someday creating the Internet of You and Me (Check out the book Nexus by Ramez Naam)!!!

If you look around us the average car in the US since 2007 has 60 microprocessors’ some connected by radio links to the central computer of that car and these electronics make-up nearly 40% of the cost of the car itself. Think about the number of networking devices that will be needed to cater to all these Internet connected devices. Think about all the software coding needed to get the products to “reason” with each other. Think about all the marketing companies rubbing their hands together mining all the data produced from these IoT enabled devices. Finally just think about the sheer number of microprocessors needed to be manufactured for each individual smart product and the sum total of everything needed to create the IoT and the number quickly become mind-bogglingly huge both in sheer volume and value.

The IoT has now become a concern of everyone because it will create greater economic value for the global economy. Gartner believes that the value for the IoT enabled economy will be 1.9 trillion USD by 2020 or for comparison about the size (GDP wise) of the tenth largest economy in the world today. The Internet of Things enables companies to develop customized solutions that are optimized for each individual customer which will in turn enable companies to adapt new innovative business models creating new markets and a new economy.

Countries and International organizations have started fostering and promoting the IoT. The US Government has started promoting the IoT as the “Cyber-Physical Systems” hoping to improve safety, sustainability, efficiency, mobility and the overall quality of life. The EU hasn’t been hanging back either in the EU Commission Digital Agenda for Europe report they say “ it could generate billions of Euros that easily translate into growth and employment, provided it ensures trust and security for the European citizens and businesses. At the same time, the IoT will bring hyper-connectivity to a global society, using augmented and rich interfaces” while in the upcoming Sixth Annual Internet of things Summit EU stake holders are coming together to discuss what is happening and what is going to happen. China has already invested 800 million USD for the IoT and Chinese Premier Wen Jiabao identified IoT as an “emerging strategic industry” in an interview on state media. The UN itself got into action predicting the IoT back in 2005. Other countries are each gearing up for the coming IoT world.

So in the future if your shoes suddenly say your foot smells and asks you to change your socks or your toaster rebels and says that the doctor has ordered you to cut down on carbs or if your girlfriend says she is too busy talking to her flower pot to meet up with you don’t be surprised. After all you’ll be living in the world of the IoT. Rather let us say “May the IoT be with you”!

Stay with us more IoT stuff to come soon!

The Internet of Things and You

Imagine This

You wake up in the morning to the alarm of your smart phone, yawning, you speak to the phone “run routine 3”. The windows to your bedroom turn from opaque to clear as sunlight from outside floods in. Automatically the coffee machine switches on, the 3D Food Printer comes alive printing your breakfast according to the preprogrammed menu. While your breakfast is being prepared to perfection, you get up to go the toilet to wash up and well do the stuff a lot of people do in the morning, your toilet reads your health situation from sensors built in to it monitoring uric acid, albumin and sugar levels. The Bathroom mirror displays some of the breaking news and any messages you might have received at night while your smart shaver reads the contour of your face using a small laser to read your skin condition and deftly control how close a shave it will give you. You eat your breakfast while your fridge details the state of your groceries. You get ready to go out. As soon as you close the door the home maintenance system shuts down the air-conditioning and all non-essential appliances. 

You walk to your garage place you finger on the security sensors that reads your finger print and along with a signal from your cellphone, disengages the lock on your car. You get in and your car greets you and asks where you would like to go. You say “to my office” the cars computer goes to a database to see what the road conditions are including weather and traffic situations. It plots the optimal route, prompts you for the go ahead and starts on its way while you recline in your seat and review the 3D holographic presentation that you had made on your smartphone. You reach your office without even touching the steering wheel.

This is just a small example of the way the world is evolving around us. Much of this might seem to be nothing but some excerpt taken from a science fiction novel but many of these technologies have already been developed or are in prototyping stage and will be around us over the next few years. This will be the World of the Internet of Things (IoT).

“Internet of Things” What is It?

The easiest way to understand the Internet of things would be to look around us at all the object or “things” that we use most of these objects are inanimate or more simply dumb, they cannot operate without human decision or intervention. The Internet of Things IoT will change how these objects are used by allowing them to not only communicate with each other but to share relevant information over the internet, allowing them to make decisions autonomously. These smart objects or things will be embedded with electronics, sensors, software and connectivity to enable them to achieve greater value and service by exchanging data with the user, manufacturer, operator or other connected devices. Simply placed the Internet of Things will allow us to have person to machine (or device) communication, machine to machine communication (or device to device communication) and machine to person communications all enabled through the Internet.

The Internet of things is set to change our journey in to the future. The way we interact with world around us and how it interacts with us in turn will transform our mundane lives into something more interesting for sure. That is why I will be gradually publishing a series of articles for you all related to the Internet of Things (IoT). So stay with us for our next parts it’ll be fun.

The Art and Science of Website Design

One day whilst at a museum showcasing art by a very famous artist a 7 year old boy stood in front of a painting showing a single brown dot, a blue sinuous line and nothing else. The painting was apparently of a woman sitting by the riverside. The child turns to his parents and says “hey you know I could draw that” much to the laughter of the surrounding patrons. Then what exactly made this painting by such a famous artist so special? Was it the simplicity of subject, idea and form? It was design.

Design is all around us whether natural or man-made. We always try to differentiate something by comparing designs. Whether it is a simple cellphone, a piece of furniture, the home we live in, the food we present and eat, anything we do has aspects of design incorporated in to it. So when it comes to a website that is actually our way of declaring “hey I am here this is me” design plays a pivotal role in capturing the attention of our intended audience as well as communicating your message.

Website design is an art and a science. Why? Well if you look at the millions of websites on the internet all vying for attention it is easy to realize why so much effort is placed into design. Starting from statistics, consumer behavior, psychology etc. elaborate attention to what processes get the largest audience and readership have become a science for website design. If we look from a different perspective attractive websites are no longer simple pictures or texts jumbled together, they contain audio, video, stunning images, and are increasingly interactive all making website design an art.

“To Be Or Not to Be” A Great Website:

So how do we design a great website? Well the first thing to think about while designing your website is what you want to communicate and who you want to communicate that too. That is targeting your audience with the right message. Most people will not spend a lot of time on a website browsing through material so it is important to keep your message concise. Think in terms of branding how do you want your audience to remember you and design your website accordingly. List out the main things that you do or want to express, make sure you do not drift from your main functions as this will dilute any message you wish to convey.

“Emotions Are Good” for Website Design:

Good websites are designed to have a personality of their own. It may have humor, be serious but it should invoke in the visitor some kind of emotional response. Employing images, animations, audio or video can easily grab and retain the attention of the audience as well as make it more attractive at an emotional level. Websites with images of faces and people also help to make your visitor feel more at home using sentimentality gives your website a much more personal appeal.  Check out the Moto G Website

Simplicity Equals to Sophistication

A great way to really loose the attention of a visitor to your site would be to cram it full of needless information and have a cluttered design that would quickly exasperate any visitor as they tried to navigate the site. Often the simplest designs are the most attractive so don’t go overboard by adding too many elements to your website. Clean designs are something Apple does very well 

Interactive Website Design

People love to interact with their environment. Adding interactive elements to your website increases its appeal significantly. The user experience becomes more personal leading to a richer more memorable experience for the visitor. Adding elements like sound, or other audio visual stimuli that appeal to one or more of the human senses lead to a positive experience for any visitor. Keeping the visitor involved doing something on your website means that they are bound to spend much more time going through it. Here is a good example... try out their fidgety menu bar!  http://rog.ie/

The People and Process of Website Design

Bringing together the multifarious elements of designing a website can be a daunting task. That is why it is important to have a team who know exactly what needs to be done to get your website up and running. The team should be able to cover all aspects of website design including coding, art, prototyping, customization, testing and validation (etc.) just to name a few.  The ability of a team to create responsive designs, inspirational outlooks and looking at issues from a different perspective all contribute to the designing of a great website.

That is why we at KAZ software have the some of the most experienced professionals from diverse backgrounds dedicated to give you the best website you can have.

Barbecued dog is good for software

Sorry for the show of the bad taste in the title. It is however not completely done for the sake of sensationalism. The idea for the title comes from a trip by the sea that we at Kaz software went to. We did a big barbecue of a whole lamb spit roasted on top of an open fire on the beach. Somehow someone claimed that it could easily pass on as a barbecued dog and that phrase caught on. So in the folksonomy of Kaz a barbecued dog party is where we do a barbecue under the open sky - something that we do at every chance we get.

So why is  it good?

It's good for different reasons. But at the core they are all the same - it brings people together and creates a bonding. There is something in making food together sitting around the open fire with smell of burnt meat in the air that brings out a very innate human bonding. Maybe it's the left over traces of a hunter gatherer tribe, maybe it's the psychological security and assurance we feel in the act. Whatever it is, it works like magic in making friends. And as we are all aware, a gelled team is the biggest factor for a successful software.   

5 Easy steps to kill the deadly PDI in your software team

PDI or power distance index is deadly for your software team.

Don’t know about it? You must read up all about it from our article about the power distance in software teams. Here is how I define power distance in the software teams:

How likely is a junior programmer to tell a senior about an error in the latter’s code?

Teams with large PDI will end up with those errors not discussed and resolved and thus with a buggy and at the end of the day a failed software. Thus it is of utmost importance that PDI be reduced in a software team.

The big question is: is it possible to reduce PDI? A valid question since PDI has been shown to be tied with cultures. But it has been shown that with the right effort and plans the cultural hard wiring can be overridden and PDI can be reduced and lives saved as it turns out:  in the case of Korean Air in late 90s. 

Korean Air had more plane crashes than almost any other airline in the world for a period at the end of the 1990s. This trend was finally pinned down to essentially power distance in the Korean culture which makes co-pilots very deferential towards the pilot and effectively cutting off the check and balance in the cockpit. Korean Air completely changed the trend by recognizing that PDI exists and taking steps to counter it. The success can easily be seen by the sudden reduction of the air disasters from the early 2000.

Although no study has been done in Bangladesh on PDI, but I can tell just by knowing our culture (and also looking at PDI scores of neighboring India) that the story is bad. So we’ve been very careful to take steps to reduce our PDI here at Kaz Software. Over the years we’ve tried lots of things but I can distill them all down to 5 steps that I know works likes magic. Here you go:

1.    Make your team aware about the risks of power distance.

The great thing about software team members is that they are uber smart. If you can make them aware of the risks of power distance and how it affects their work product it immediately has an effect. This is something we do at every chance we get – starting from the day someone joins us and continuing at almost all the team meetings and brainstorming sessions. The awareness gives the team members to speak out when they worry if speaking out against a senior might be being rude. Which takes me to the 2nd step.

2.    Train your team to be rude!

Well at least train them to speak out. Being nice and well behaved is the worst things that a developer can do to his team! Train them to have a strong voice of dissent, of being not nice when it comes to reviewing code or software design. A big tradition at Kaz is to “introduce” a newbie to the fine art of saying “you are dumb” in multiple ways!

3.    Make self-deprecating humor common

This is slightly more difficult. But if you can plot this with the seniors in the team this becomes the easiest way to break the ice. A common joke at Kaz is that seniors can’t code that well because they are slowly losing their grey matter. It’s brought up at every chance we get when we worry about code – and soon enough the juniors in the team start to use it.

4.    Do events that break down the barriers

These could be during the ubiquitous “team building” events or events specially designed to reduce PDI. The aim is to create a feeling that we all make mistakes – so the goal is different from the usual team building event’s goal – different enough to make special plans for them. The idea is simple, setup a situation (in a game, a show, etc.) where juniors have an edge over the seniors or where the seniors intentionally make a fool of themselves for fun. At Kaz the team leads dressing up as dodgy looking ring masters of a game are a good example.

5.    Make team structures as flat as possible 

This is the most important one. It’s the strongest message that you can send to the team about your intentions of keeping the PDI low. The whole gamut of hierarchy and respect just doesn't work in software and the sooner you kill it the better. 

The deadly power distances in a software company

It all started with a Geert Hofstede, who in the late 60s did extensive experiments to prove that how we operate in a corporate environment is very much a function of our national culture. He measured responses of 117,000 IBM employees (he was working with IBM at the time) across different countries and showed that there are distinct biases about our reactions based on where we are from. He grouped the attitudes he was measuring in four types and called them the cultural dimensions. 

Of these dimensions Power Distance index (PDI) is the most interesting, I think, for software companies. Power distance is in simple terms how submissive (or not) is someone to his superiors in a hierarchy. For a software company it boils down to a simple question:

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

If he is likely scream at the first chance then the power distance is low and if he is more likely to not raise an alert the power distance is high.

Hofstede showed that PDI is directly correlated with the country you are from. And this makes perfect sense - some countries have culture of strict hierarchy where are elders are honored without question. These cultures imbibe its children with that value of respect and submission to seniors that obviously shows up in work culture. Countries with high PDI include India, South Korea, Malaysia (sadly no data for Bangladesh, but it is without doubt a high PDI country). Countries with low PDI are US, UK, New Zealand etc.

So what is wrong with high or low PDI? 

Well, it depends I guess in which work area you are in. I'm sure high PDI is great for families (oh how I wish my word be the law for my two unruly sons - high PDI is definitely welcome at my home!), high PDI is probably good for places like the army (when you tell your soldiers to jump in front of machine gun fire you don't really want them to point out the futility of war, e.g.) but for some industries it's downright a disaster (literally). In 1994 Boeing published safety data showing a correlation between a country’s plane crashes and its score on Hofstede’s dimensions. And it is easy to understand why - in such a complex operation as flying a modern aircraft the chances of error are high for the captain. The first officer's major role is as a second pair of eyes for error detection and mitigation. Yet in high PDI countries the first officers (much lower in the hierarchy of things compared to the captain) finds it difficult to voice their concerns. And when you have that over millions of flights you start getting statistically significant effect of the high PDI causing crashes to happen.

And so it is for software. One of the basic facts in the game of software is that everyone (including the uber geek who has been programming since the 90's - well specially him!) will make silly mistakes. The only way to save a piece of software from these mistakes is by constant double checks. Software QA is a double check for sure, but that as we know is way down the path. The earliest double checks are the screams of team members during the design sessions and coding. And this is why a software company craves (or should crave) for ultra-low PDI. This leads us to a simple statement:

Software can only be made faster and less buggy by having low PDI.

So the most important question for a software company then becomes 

Can PDI be lowered?

  And thankfully the answer to that is 

YES!

The important thing is to recognize that there is a need for lower PDI and then there are many things that can be done to lower it. There are documented proof of such efforts and the resulting wins in the airline industry. We at Kaz Software have been doing that for the past ten years in our little niche! 

How? The answer to that question will be another blog coming soon.

 

Java still loves you - Please wait

You must've got that irritating message popping up when you log-in to your windows where it says there is a new version of Java available (or even worse the windows UAC pop-up with the worrying question of "Do you want to allow the following program to make changes to this computer?" ). Well take solace in the fact you are not the only one in history - Java has been irritating the humans with this for quite some time. Joel even wrote a small article in his blog as far back as 2009 and came up with the wise words

 

"...This whole damn dialog could read

Java Loves You—Please Wait

without any loss in functionality..."

Well nothing has changed in the intervening years. The message is exactly the same wildly pompous message of 

“By installing Java, you will be able to experience the power of Java”

Actually somethings have changed - Java is now Oracle and the UI has managed become even worse (how they managed this feat is amazing though, extra brownie points for the red java.com hyperlink).

Then ...

And now ...

PS. Just a quick disclaimer- we are no Java hate group, actually we love it. Kaz Software has a very strong Java team (it has always had one right from our humble beginning). We work and have worked on all sorts of Java based web applications and love the robustness of the platform.