Get your software done.
The Kaz Software Blog publishes articles about how you can make great software and launch your product to market.
VR is a whole new ball game when it comes to Ux, software development and testing. This article goes over our experience in testing the VR game we are developing for one of our customers.
Read MoreAs 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...
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.
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!
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!
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.
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.
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 :)
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.
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 :)
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
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.
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.
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!
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.
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:
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
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?
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.
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.
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.
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.
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 ..."
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..."
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..."
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..."
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
… 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.
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 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.
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.
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...”
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.
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.
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.
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.
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.
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!!!
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.
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!!!
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!
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).
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.
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.
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.
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
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
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/
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.
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.
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:
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.
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!
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.
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.
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.
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.
