Software without anger: managing vendor relationship

Isn’t that a great title for an article about software development? If you’ve ever been involved in a software development project this would ring bells! And if you have not been, but you are thinking of starting a software company or working with a vendor to make a software you should definitely learn about this. Because want it or not, anger will come. You’d be very lucky if it’s only once in a while that people are angry, it could easily be that the whole project is a series of angry exchanges!

FEAR NOT.

This is a problem that can easily be managed (if not completely avoided) if you take some simple steps. So here goes our strategies for anger managed software project. I want to split these strategies up in separate articles, one about managing anger between you and the outside software development partner, one about strategies to use to manage anger when your developers are in house and the last one about strategies to manage your own anger (remember, you are sometimes one of those angry people)!

Today’s article is about strategies for managing software projects that are outsourced to custom software development company like us.

1. Expect and accept anger as normal in software development.

   In any endeavor where there is a lot of unknowns and yet the risks and cost of getting things wrong are big anger is natural. Anger is actually sometimes good sign in software projects - it shows people involved in the process are emotionally attached to what they are doing and they care enough to voice things out. It is the negative aspects of anger like the blame game, shutting off channels of communications, creating bias, etc. that are destructive that you have to be worried about. If you expect and accept the fact that there will be anger, you can take steps to reduce it, manage it or channel its energy to a creative force.

2. Know that software development is a fluid process.

   The top thing you need to understand when you are managing anger or designing a process to reduce it, is that software development is inherently a fluid process. You just can’t have it structured as precision engineering process (e.g. like a building a bridge) where everything is thought out and can be measured. Every step of the software development process involves reviewing what you initially thought needed to be done and changing it. Remember why Agile process is so successful - “embrace change”. So all your contracts, documents, dev cycles, demos, monitoring, analysis of work should have the possibility of change taken into account. For example your software development contracts with the vendor should have clauses to cover situation where there are changes. Timeline and delivery milestones should have padding for inevitable change. The list goes on.

3. Scope, scope and scope.

   The full software will probably do a lot of things one day (maybe even change the world) but for the small block of time that you are working on, or the immediate delivery you are waiting for will only be for a small section of those things. So you’ll need to first identify clearly what you want to achieve, define and document those features and then communicate that to the developers. You are scoping the limits of a delivery. If you do that clearly, right up front and stick to it (as much as possible without harming your business) you’ll get rid of most of the destructive anger in a software project.

4. Have regular scheduled meetings.

   As the software is being built offsite by a team that is not always in touch with you regularly things can easily go in the wrong direction. It’s essential to have regular meetings at short intervals. That makes it easy to find errors early, give feedback early and get the development back on track faster. Bunching up a lot of development work to be reviewed in one go is a recipe for disaster and fights. It is counter productive and actually wastes much more of your time than the time you thought you were saving but not doing regular meetings. How regular? Depends on the nature of the project, but I will say the meetings should never be more than weeks apart.

5. Create an environment of trust and collaboration.

   For a software project that is outsourced this is a really big one, and most of the responsibility fall on you as you are the ultimate customer as much as the software team is concerned. You set the tone of the collaboration. If you set it so that it’s always combative then you’ll have your vendor always trying to be defensive. They will hide things from you, be less proactive, less likely to point out errors on your part. Set the tone from the start that you have trust and that the project is a collaboration. That will make way for conversations that addresses issues with reason rather than emotion or subterfuge.

6. Always celebrate victories.

   Make deliveries and reaching milestones a big thing. Treat your team to a party, give them some symbolic gifts (even a congratulatory email goes a long way). This celebration renews the relationship, gives it the time to rest and prepare for the next cycle. And most importantly this celebration makes it easy for people to forget bad feelings and make them move on with renewed energy. It is like the restart button on a game gone wrong!

That’s all for today, wait a bit for my other one about keeping your in house development process happy. By the way this article was my chance once again to use old black and white pics stolen from the web particularly of the three stooges. We used to have this as a tradition for all our articles some years ago!

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.

Interface between technology and business

The interface between technology and the business side of the team is always something similar to friction between plates in the theory of plate tectonics and with very similar side effects! 

If you search the Internet on this topic you are bound to come to the swing in a tree cartoon. It describes the situation very well in pictures and I give an example below. (Side note: There is surprisingly a lot of variation of these cartoons, from black and white to color with variations on the actual content too. They seem to have been around from the pre-computer age and have just been adapted to the newfangled contraption and all the problems associated with its management. This tells us once again that the management of IT projects is just a new variation on an old theme. Here is a very interesting account on the swing cartoons and their origin.)

So the question is how to make the interface between technology team and business teams friction-less? And I think the answer lies in first accepting that you can't - you can only try making it better lubricated. With this first acceptance in mind, here are some of the things we as a custom software development company do to keep the interfaces lubricated well.
  

1. Let there always be a middle man

If there is a middle man in between the business and the technology teams then that middle man can translate each other's language. The classic middle man is the CTO or project managers but smaller projects we set one of the roles as the middle man role. We have seen that the putting on the middle man or interface layer hat changes the mindset of even hard-core developers and pretty much everyone can do the job but obviously the project managers tend to be better at it since they have more experience. Note one thing though, our project managers are always ex-developers so they can speak the techie language well and so it works pretty well for us. If you are one of those unlucky places where the PMs of software projects is not a techie, then this might just add to the friction, so be careful.

2. Let everyone speak a lot before anything is done

Sounds obvious right? But you'd be surprised at how many projects this is not done properly. We let every member in the team talk a lot about requirements - breaking the rules of not having prolonged meetings. We do these meetings as many times as possible at the cost of making everyone irritated and bored. We have found that this is a small cost to pay when you compare it with the benefit of a better understood set of requirements.  

3. Always do a "prototype" 

Sometimes the "prototype" is not something you'd call a prototype in a tech crowd! It could be half working quick and dirty app, or it could be just a bunch of pictures glued together in html pages some parts of which are clickable. But whatever it is, it helps clarify a lot of issues and makes the business teams see how things will look like or may work. It gives them the chance to scream or modify their expectation or modify their plans.  

4. Have regular meetings to show case the product in its current state

We call these internal product demos. Ideally they should be done with the project manager showing it to the business people as potential customers! The whole tech team should be there, to see the reaction and hear the feedback. It gives directions and food for thought about what is being built for the whole team - business and tech alike. 

5. Let business team see the product at any time

This is the classic Agile recommendation that the stakeholders should be able to see the current state of the product at any time without going through any red tape. This is actually very easy these days with build systems and automated deployments frameworks in place. The whole thing should be automated, so that at the click of a button the business guys can run the app and check things out.  

N.B. Just in case you are new here: we are a custom software company  in Bangladesh making custom web, desktop and mobile apps for other companies and being very good at it! Check out this page to know more about our software development work culture and environment.

Mobile application development - lessons for an old dog

They say you can’t teach an old dog new tricks and we would like to modify that adage slightly to “you can teach an old dog new tricks, but you need to give him a shock therapy!”. 

And shock therapy it was for us when we first tried out the wonderful world of custom mobile application development. We’ve been in the business of custom software development for a long time, and when a client asked us to do their mobile app on iOS and Android a few years back – we just thought it was just another technology to move into but how wrong we were.

We had done pocketPC (windows CE), Symbian and Palm development in the ancient times – and then there was a gap of a few years when we had that iPhone app to do in late 2008. We did the app for sure and it was a great success too – but we knew that our process was all wrong. We only managed to get the app across the door because of sheer strength of our talents – but we took too long to make it, we messed the UI on our first attempt and we had no idea how to manage a project of this type.

We have moved a long way from those early days. We have learnt a lot in the process and know now that in the fast paced mobile app work the processes, interaction design, development methods and QA takes a completely new form. And once you know the truth, everything becomes simple and the old dog can do new tricks with its style again! We now have a strong mobile apps team making apps of all kinds on iOS, Android and Windows Mobile for happy clients.

I want to share today the lessons we learnt about non-tech aspects of mobile software development.

UI is everything and it’s totally different

This is the single most important thing we learnt. UI in the mobile space is completely different from anything you have learnt on any other platform. So our designer needed to start from scratch (and in addition we hired mobile UI experts too), learning the UI paradigm.

Tapworthy: Designing Great iPhone Apps

By Josh Clark

And to make things difficult UI is the most important thing in this space. If you don’t get UI right for the app then there is no point in making it. Mobile users just won’t give your app a second chance if you get a single thing wrong in the initial interaction. It’s an extreme version of the short attention span that website designers worry about.

This is the top thing you need to get right in your team. There are a lot of books, websites and training on this area these days. But one book stands as our Bible, we make it required reading for everyone (including developers) in our mobile apps team – Tapworthy by Josh Clark

Kill the PM as soon as you can

Coming from enterprise or large software world, we tended to think that every project needs good continuous project management. Not so in typical mobile apps – you need initial project planning for sure, someone coordinates the resources and finalizes the UI etc. But once it gets to dev stage (which is pretty early) the notion of the PM role should be gone. Developers can easily manage the process and coordinate with other sides and having an external role here just slows down the flow significantly. So the lesson learnt is plan out things and then don’t plan anymore!

Be addicted to apps

In no other platforms is it so important to be following the trends. The trends in graphics, interaction, placement of buttons, type of apps, how are freebies given out, you name it. It seems the whole apps using population swings to new direction at the first chance and knowing where people are moving is essential information. So everyone in the team needs to be downloading and using mobile apps like crazy – it’s the only way to keep up!

Build a collection of devices

No matter how great the custom mobile application code works on the emulator or the device in your hand you never know how it will behave in the device of your user. This is very true for Android but just as important for other platforms (even iOS). And in the crazy mobile hardware world, to get a device even an year old can sometimes be extremely difficult. The only way to go is to start building a collection of devices and not updating software all the time!

Stay informed about the appstores

This is something that is never quite needed in any other platform. But in the mobile space the delivery marketplace (e.g. Apple appstore, Google play etc.) is extremely important. They are like dictator states with their own set of rules which change at a moment’s notice. Knowing the appstore policies by heart, following news and blogs about them and reading mail that you would have usually considered spam from them are an important part of the mobile software building.

Know the basics in latest app marketing

In most other branches of software the non-techies take over marketing (and other such fuzzy things). But on this new and ever evolving mobile apps software scene everyone needs to have an idea about app marketing. Interaction designers need it to plan where to squeeze in the ask for money line (or to know if it is appropriate to ask for money at that point or not) and developers need it to know which part to speed-up the most, what tools to use or the politically correct library to use in the interface. I am not joking, it’s really a frontier science this mobile application software development!

Deliver before the deadline

OK, this one is always the best advice on paper. But amazingly this is expected in the mobile apps development. Its expected since it’s really one the things that may make the app survive as a business. The competition is extreme and any new niche (as if there are any) gets filled up instantly. So any delays are really disasters. As more and more companies get into this space this is becoming even more difficult – so we may have survived with delays in 2008 with our first app but today it would have been a disaster.

So you have to plan for early deliveries. You do the usual things you do in software projects for such thing – prioritize, compromise and sometime throw in more people (forgetting that pesky book about mythical man-months). But you do them right from the start!

I think that’s about all the non-tech lessons we took – but there are a lot of tech lessons too. Another day, another article.

N.B. Just in case you are new here: we are a custom software company  in Bangladesh making custom web, desktop and mobile apps for other companies and being very good at it! Check out this page to know more about our software development work culture and environment.