Posted: August 25th, 2014 | Author: Kent Nguyen | Filed under: Development, Personal | 2 Comments »
Managing several projects at the same time is definitely not an easy task. Doing it remotely is an even greater challenge. The most consuming task of all is no doubt communication: getting updates, reading reports, spotting potential the roadblocks, knowing critical events, etc…
I’m running a relatively large remote software development team of 40+ people. At any one time, I’m having my eyes on no less than 10 projects and I need to maintain detailed mental status of every single one. On top of that I also need to be involved in strategic planning, sales, accounting discussions, remotely. At the end of the day, I’m still doing coding and bug fixing for some of the projects.
Most people would tell me that’s an insane level of concentration and a lot work.
It is not true. Since the introduction of Slack, I believe I’ve finally formed a system that keeps things well under control and allow me to run the team with extreme confidence everyday. I still have some spare time to enjoy what I love to do.
I hope my experience in the form of specific & practical steps could help you to reach a high productivity level and most importantly: staying sane.
To begin, if you are not familiar with Slack, please do some Googling and try it out. Here are some numbers extracted from my team’s dashboard:
On a normal day, I’d actually read about 80-90% of the messages including the messages from external integrations. The active number of people using the platform is close to 40 all the time.
On the day Slack was released to the public, as a team, we switched over (from Skype) completely in less than 48 hours. I gain nothing by promoting Slack but I have to say it’s by far the best team communication platform we have ever had our hands on.
Channels, groups and the water coolers
I’m assuming you are aware of the different concepts in Slack. We did not deviate too much from the intended setup:
– Channels as public discussion topics such as #design, #ios, #android, #ruby…
– Private groups are project groups consist of specific people, by invitation only.
What makes the team special is that we adopted the concept of digital water cooler. In our setup, we have several ones such as
#general #music #games #dailyphoto. They are essentially public channels with gossiping intentions.
The digital water coolers are an engaging, asynchronous and non-distracting way to keep everyone connected in an informal context. When often about half of us are not in the same physical space, it has became invaluable. It also keeps the fun and work in the same interface.
Getting all the tools in one place
Similar to a typical development team, we have a handful of tools for different purposes. Normally, we would need to setup email notification for each of the tools. It has always been difficult to get notified about smaller, trivial events such as when someone pushes code commit or when a comment is made to the task-card. Imagine multiply those by factor of 10+, things get out of control pretty quickly. Most of these bits are insignificant as we see them, but occasionally could be a tell-tale sign to a potential disaster.
So when the team switched to Slack, we wrote our own custom integration code, consolidating all possible events happening around a project into its specific channel. It is a major shift in how the team members work together. Individually, we no longer need to check for tasks assigned or new comments on Trello, or check for bug report on another system. We’ll know about them as they happen and we keep a history to refer back to.
Personally for me, I now have much better visibility into any project, It was simply not achievable before. I could see when a specific bug has been fixed, new version deployed, or I could choose to ignore them. It’s up to me.
Turning off distractions, partially
This is the secret of how I stay available and informed all the time yet I don’t have to really be online. It is probably the most useful and most important feature that Slack offers.
What you see above is the non-default notification settings that I keep for most channels and groups that I’m in. By keeping the option this way instead of the default option, it reduces the distractions on my desktop and my phone.
I don’t receive the annoying pop-up message all the time when I’m working on something. I will read the backlog either on my phone or my Mac when I have some time in-between meetings. Usually it takes me only a couple of minutes to catch up.
Some rules I followed to keep it to a very manageable level:
– Water coolers: all notifications off.
– Private groups: partial notifications.
– Other public channels: only notify on desktop, no mobile.
If you are not aware about this setting now, try it today and maybe gain back your ‘peace’.
Staying alert of only what’s important
I turn on All Notifications for certain threads, they fall within the following categories, these usually require my immediate attention:
– Management group
– Finance/HR group
– Direct messages
– Project groups that are in delivery phase.
Another subtle yet brilliant feature Slack platform has is the delayed notification. If I don’t read the message on my desktop soon enough, after a short while, probably a minute, it will push the messages to my phone. And since I practically keep my phone next to me all day long, I would not miss out.
Notifications were PITA for Skype. All messages are pushed to the mobile app. It quickly became overwhelming and the non-critical messages bury the critical ones. There was simply no way to work around this annoying issue.
Catch the critical events
By default, if you
@mention anyone in Slack, they will get a red badge next to the channel name on desktop or they’ll receive a push notification to the phone within a minute if unread. This has been extremely useful for team members to request for attention from other team members, whether they are online or not.
The underlying mechanism in Slack watches for your own username as one of the important Highlight Words. So to stay updated and be notified of all relevant conversations and events, I added a few more specific and generic keywords into the list: crash, structure, test failed, NoMethodError, different spelling of my names.
This way, I could stay informed about most of the critical events and decisions. I could also catch it when the team is discussing about architecture design and then drop in to give my opinions even when I’m not being mentioned.
Clearing the messages, quickly
I receive an enormous amount of messages at any time during the day. At first it was overwhelming, but gradually, I developed a systematic and efficient way to read and response to all communications.
Since I’m on the move very often, I would only try to read threads with a red badge on my phone follow a certain order of importance:
– Direct messages
– Private management groups
– Private project groups
– Other channels or groups
When I got back to my Mac, I’d use the hotkey combination:
Alt + Shift + Up/Down to jump quickly to the next unread thread. On top of that, I use
Esc key to mark the water cooler channels as read without scrolling through them. I would go back to read them when I’m done catching up.
This arrangement allows me to work through the daily communication effortlessly. I don’t need to actively spend time chasing people for updates and reports and yet I know when the code failed, why apps crashed and how the team would solve the issues.
With Skype and other platforms we’ve tried before, it was simply not possible. The model was still pretty much a pull model, that is I need to “poll” for updates. Since Slack came along, the game has changed. Now the updates are being “pushed” to me in smaller chunks, my job is to digest those on my own terms.
Not only it that, whenever I feel overloaded, I allow myself to drift for a short while. Simply turning on Do not disturb on my iPhone and let it be. Having an absolute peace of mind knowing that when I’m back, things will be waiting for me in the right priority.
I keep an eye on no less than 10 projects efficiently at any one time with the help of Slack platform. By default it has some brilliant features and smart notification but you’ll need to tweak it depends on your context. Once you formed your prioritisation rules and setup the channels, staying updated is no longer a time-consuming task.
Posted: April 8th, 2014 | Author: Kent Nguyen | Filed under: Development, Personal, Perspective | 6 Comments »
Two years ago I wrote “Dear business people, an iOS app actually takes a lot of work!” and until today I have not really revealed publicly how it was the little accidental ‘overnight-success’ I had. So here it is: on the first day it stayed on HackerNews‘ front-page for a breaking record of more than 48 hours (a usual indie link wouldn’t stay more than a couple of hours). My server crashed more times than I could count and the highest live visitors on site recorded to Google Analytics was close to a thousand viewers, that’s 1000 concurrent connections at any one time. Until today, I still have few thousands view on that article every month without doing any promotion.
So I decided to write a “version 2.0” given the extensive experience I have had while assembling a great team and started building mobile apps professionally under Silicon Straits Saigon. Instead of looking at the various cost consideration factors of building an app (which the previous article still reflects very accurately in 2014), I would take a different approach by giving a sample timeline and rationale why things need to be done in a certain way.
Let’s say you have decided to build an app that allows users to post and share cooking recipes but you want to own every aspect of it including servers, source code. You also have this super niche audience group that you want to target and it will need certain features that no other recipe-sharing app out there have it. Of course, you might have all those ideas in your head but there’s nothing written down in black and white.
And very importantly, this article assumes that you are serious in building a nice-looking and solid app, not just dummy or disposable prototypes. Moreover, I am discussing development of native apps and not cross-platform solutions. Sure they could potentially save time but nothing really beats individual native code when it comes to long term benefits.
It’s going to work for sure, you know that the idea is solid, right?!
Hopefully, after reading my previous article, you now probably accepted the fact that you are not going to get it done cheap.
To make things more realistic, I would also assume that you don’t want and can’t afford to pay for a huge lum-sum upfront to the developers/company you will engage. This is also true for SMEs/individuals/agencies who need to maintain a low monthly burnt rate to survive the longest time while working out marketing and launch plan. Sounds familiar?
With that in mind, what I usually propose to my clients is a monthly arrangement with bare minimal headcount of 1 for each skill-set needed to complete the app. And in this example, let’s say you need 1 back-end developer, 1 iOS developer, 1 Android developer. Make sense?
In case you are expecting one developer for everything then please stop reading this and go back to your day job instead. Unicorns do exist in some forms but you are no where near their league.
If you are still unclear, look at the Timeline below.
Surprise?! I said only 3 developers but now there’re 5!!! What’s going on?!
Don’t freak out just yet, let me answer all that burning doubts one by one:
+ UI/UX Designer: Why do I need a UI/UX designer?
Don’t worry this is pretty common misconception. Most people when thinking about “making an app” they actually think of “copying” an existing app with similar design or maybe borrow a design from another app. Another gap in expectation is that decision makers think developer can also design, which is not true most of the time. Putting this together, the business owner usually assume it’s simple for the developer to plug design pieces from elsewhere and put in the app easily.
NO! You need at least a proper designer and the next guy (below) to even begin realising the app.
+ Product Manager (PM): What is this role and again why do I need him?
You don’t have any written documents, maybe you have some napkin sketches but that will not be sufficient to convey everything exactly the way you want it to be built. And developers, they don’t talk your business languages, they don’t care if you wanted nice design or reach thousands users, they can’t fill in the blanks for you. This PM guy will the interface between you and designers and developers. He will also help you to ask you questions that you probably have never thought of while drawing on those napkins.
Arguably, you can make an app without a PM for sure. But based on my experience, the project will drag much longer and you will never get to the satisfactory level that you hope for in the beginning. It wouldn’t be a smooth sailing experience.
There are also several reasons why I always refuse to call my PM as Project Manager, this deserves another long post that I intend to publish soon. The bottom line is Product Manager is more than just Project Manager. Subscribe to my blog and stay tuned.
I believe the explanation above toned down your doubts and you are ready to get to the real rationales behind my proposed timeline: task dependencies.
Kickstarting the app, you need the idea-guy (UX designer) to dream for you, then the creative guy (UI designer) to draw your ideas nicely, but of course, you also need the PM guy to help you put things together and plan out what is realistic and what might be too far-fetching. If you are lucky, at the end of first week you should have a very good sense of what the app will look like and what can be ready for launch based on a certain timeframe. My team has a unique creative process that make sure you can’t fly off too far from the reality within this first 2 short weeks (ask me how!).
Why can’t we just start building right away?
The issue is what should be building first? Logically, the back-end (Server dev) needs to start his work first before the “app guys” can do their jobs. A typical example why you can’t start building the “app” part immediately is this:
– You want a registration screen, but you have not decided what information to collect.
– The server dev can’t decide for you if you need to store Age or full Date of Birth, it’s up to you.
– The app guys can’t build the interface because Age is a year selection while Date of Birth is a date selection.
– Now you need to go back to the beginning to work with the PM.
So the fundamental of dependencies for making an app is this: you need concrete sense of what you want to do first, then the server work can start a little bit; after which the app can be build incrementally. It’s like the app developers will play catching up with the server developer and that’s the most effective scenario.
Your milage may varies, sometimes you might need a much longer time for UI/UX development because the exact flow is too complicated or not known in advance. My team worked with several media agencies and this is usually the case, the high-level ideas are there, but the end client (usually big MNCs), cannot decide how to do the UI and what are the functions to have.
In other cases, your server development might need a longer head-start due to complex overhead logics, example: integration logic with external servers, or in regulated industries. In the timeline above, I assume the developers are all in one place, hence reducing all possible delays and mishaps in communications.
You can only plan so much. There will be several changes once you are able to see and test the beta versions on your devices. That’s why there are half-blocks on my timeline for the designer. You should expect to work with them occasionally to revise the design and user interactions of the screens. All other work will have to be reconsidered to fit the slightly-changed plan.
Most likely you will get your iOS app ready earlier than Android. Not only because of Android’s notorious fragmentation but also because of really weird and seemingly-stupid bugs which happen only on certain devices that you don’t have physical access to. I faced many of these over the past 3 years and eventually I learnt to accept the sad truth, it simply takes longer.
How long would it take to get it done depends on how complex and detailed the requirements are. A good Product Manager, in my definition, should help you to control this while you can’t. He/she should be able to tell you to set a date and stick to it. You should not change your mind half way and take a detour because of subjective judgements of market for example. He/she should help you to manage the timeline carefully.
Don’t expect your first version to be perfect, in fact trying to push the last 10-20% til perfection might get the project killed by lack of resources or missed deadline. Just get it out there to real users already while it’s good enough.
Making mobile app is still not as simple as it seems to non-developer. In modern days, when almost every new app is Internet-connected, the process consists of more than simply iOS/Android programming. You need strong server support, you need designers and equally-important product manager. Each of these components when carried out in certain order, it should help to achieve optimal time and cost for your first release.
If this article doesn’t scare you and you still want to make an app? Contact me and/or the team at our Facebook page.
Posted: April 28th, 2013 | Author: Kent Nguyen | Filed under: Development, Perspective | 8 Comments »
While taking client works, it’s not uncommon to have to deal with bad clients. There are of course many kinds of such: the ones that don’t pay, the ones that don’t care what you do, or the ones that never satisfied with your work…
However, even the good ones (pay in time, committed, respect your work, rational …) are problematic in their own sense. In this post I’ll share my experience about whom I call half-baked or semi-technical clients.
Who are they?
There is the kind of clients who doesn’t know anything about technology, very typical energetic business guy who have an idea and just want to get it done. This is good.
And then there’s the kind who is as enthusiastic, and think that they know what it takes to talk technical. I found this to be the most time-consuming kind of clients to serve.
It’s not easy to spot them, they often appear to be nice, understanding and excited about whatever you proposed … in the beginning. They might also keep what they know to themselves and you can easily mistaken them as the non tech-savvy client.
Until… the project started.
Clear requirement, messy execution
Again, things are ok with scope and requirement. Since most of the work is on high level, it isn’t exactly technical and their thoughts are aligned with yours and they agree with your architecture model, how modules are structured and how the APIs to be designed, etc.. At this point most likely you already received your first upfront pay-check. The project’s prospect is rosy and full of rainbow.
Here’s the turn of the story, it becomes real messy when they are involved in the execution! First they think that they are giving suggestions to save your time by sending you links to StackOverflow issues. Then they also do the research for you by giving you bunch of websites to look at and say “I want this here combine with that there”. What’s the real problem here is that those SO questions are usually irrelevant or outdated. The sites that they gave are the options that you already taken into consideration before proposing the final solution. Hence you find yourself spending too much time shooting email back and forth explaining to them your choices and why the others were not chosen.
It doesn’t end there yet. When they are not convinced of your approach, they try to twist their words differently to how they understand the technologies and then “confront” you with the new version. After a few times if you are good then their version will be actually the same as yours except it is phrased differently, more lengthy, more complicated… and they are happy because they think they “improved” your design.
So far, you have not actually done much work except writing emails and stretching your brain to try to justify the underlying technical choices. Naturally, you are behind your schedule.
Destined for failure
The moment you give in and accept their way of doings, you unknowingly gave them the power and credit to continue over-shadowing your decisions. From here, you can see how it goes badly: they would question your moves, debate “technically” with you the best way to solve a quirk, even give you “minor tweaks” to the architecture that would give your heart a little break; or if requirements changed inevitably, they want to help you to “smoothen” the transition by suggesting how you should code it (urghhh!!!).
Oops, you allowed the devil in your bed.
The point is …
In the last week, I have sadly classified two of my clients into this category, one of them is actually a long-time client. There were times I kept asking myself why it was so energy-draining to speak to them and couldn’t really get out of it. Now that I kind of “get it”, I’m hoping by leaving my general observation and share my rant here, it would do good to others who are in the same line of business.
Sounds familiar to anyone you know or a specific incident you have? Leave it in the comments.
Posted: March 25th, 2013 | Author: Kent Nguyen | Filed under: Development, Perspective | 1 Comment »
What was it like
Two years ago, when I just started exploring my first job after graduation, I was very fortunate to be part of Anideo – A development lab where I was free to explore many new technologies.
Not only I had the chance to get my hand dirty with new programming languages including Ruby on Rails and Objective C, I also had the chance to meet and speak to a number of startups in Singapore.
At that time, it wasn’t a big deal at all to me, I just thought that RoR and iOS was really cool and meeting/sharing with the people in the same industry is just something that you ought to do in a working life. Little that I know, I was living in the future!
I was working with the top developers, made friends with people in the know-how, seen the top-notch designers’ work. Naturally, I learnt and extracted the best from people around:
- I used soft-gradient, soft-shadow in all my designs.
- I tracked all my projects with Git. All my works were on the cloud.
- I wrote my web application in Rails, deployed to Heroku, stored file in S3. Ofcourse, I ditched PHP.
- I made several iOS and Android mobile applications, with native and non-native languages.
I began sharing and enforcing some of the practices to my teammates:
- Enforced low contrast gradient, no hash shadow in web design.
- Tried to get people to stop using PHP and move to Rails.
- Tried to teach people to use Git properly.
- Made a decision to stop an old Rails 2.x project half-way.
- Started a small team to make mobile apps.
The practices were not really successful, the decisions were not immediately clear. I didn’t have a solid reason to make a convincing statement to the people. Everything was mostly based on gut and my own experience, not at all proven. That was over a year ago and things had been kind of the same since.
In just the past month, the dots started to connect and strangely everything I ever did a year ago started to make absolute sense to people who heard about. In the past week, literally almost everyday, there was news or an article published that gave credit to at least one of the technologies I tried to educate people.
There was a recognised trend of flat-design; A huge emphasis was being put on Ruby on Rails, more and more people want to try it out; Articles on the explosion of open source software credited to Git infrastructure; The rise of true “living software” made possible by Git and Ruby on Rails; Several companies rushing to get my team develop mobile applications for them.
I don’t know but are you willing to seek and catch the next wave?
Posted: June 7th, 2012 | Author: Kent Nguyen | Filed under: Development, iOS | 8 Comments »
I started writing a custom control for iOS since about a week ago. The initial idea was that it’s going to be part of a bigger application that I will be working on and it’s going to be a versatile and reusable component that could potentially save countless number of hours for other developers as well.
I decided to write it from scratch because there aren’t quite anything out there could do the job, although the task it serves is quite a common one: select multiple items from a long list – a generic selector/picker control. I found this, this and this, however they are rather outdated and written for a specific purpose of selecting people (phone or email).
So as I was writing it, it gets more and more complicated with several configuration options that I need in my project. That’s why it also became clearer and clearer to me that there is a need for such generic UI control. I can already imagine it being used in many app ideas that I have in my mind.
Closer to completion, I am very certain that I’m going to sell this component for a small fee, at least compensate for the time I’ve spent. Plus I’ve already written a commercial component that is doing not too badly.
The last bits of the package was the documentation, licensing and pricing. As I did some research to pick the correct license and some calculations to get the pricing, it suddenly struck me that the process of developing custom controls has instilled an idea: to commercialize every UI components that I will develop. Not a good way to think about iOS development.
Fast forward to an hour later, I found myself rewriting the About page and pushing the code to a public Github repo. So damn it, I’ll just opensource and just let people take the code, improve it and probably pay whatever amount they think it deserves.
Here is the component and here’s the commit if you are curious. Check it out let me know what you think in the comment below. Would it have been a good-selling component if I were to sell? How much would you pay then?
Posted: May 4th, 2012 | Author: Kent Nguyen | Filed under: Custom UI, Development, iOS, UX | 7 Comments »
For a long time, since beginning of iPhone programming, the modal view has not had any major innovation. A quick search on cocoacontrol for “modal” returns 3 types of modal view:
– Fullscreen cover-up modal view
– Centered-popup type
– Date selector modal
The context problem
Out of the 3 types, the date selector is the only type that keeps the user aware of the current context that he is in (date for which field). By contrast, the other types of modal view practically cover up the entire screen and none or little context is visible. These implementations have been sufficient so far and sometimes the developers just have to include some context within the modal itself by setting the view’s title or include some kind of static labels.
But what if we could do better by adopting the same interaction by the date selector component? What if we need to somehow keep most of the context visible while presenting user with supplementary controls for adjusting behaviors of the context?
The Park Guides app by National Geography
The beautiful Park Guides app (iTunes link) launched just recently in Apr 2012 did an excellent job in solving the context problem.
So instead of the usual fullscreen modal view/popup view/UIActionSheet, the app shows a semi-modal view on top of the current view similar to the date selector component. However, the most interesting feature of this app is the way the current context is kept visible using a nice subtle animation. Instead of simply dim the view in the background like UIActionSheet, the entire view is scale down to about 80% and pushed back like a stack, creating a unique wow effect and at the same time, more of the background view is visible to the user. This is a great new way to interact with iPhone components.
It’s best to view the effect in a video clip here (1.3MB, .mov)
When it works, when it wouldn’t
Arguably this fancy implementation may not work in all cases. If you have a long Settings modal view in your app, it is not suitable. Or if you have a modal screen with text input, it wouldn’t work at all.
Nevertheless in many of the use cases it will be excellent addition to your app. Say for example you have a long Settings screen and different Tabs in your app, you might want to consider breaking down all the settings into different places where they are being used there and then.
Another use case showed in Park Guides app is providing extra content to the current view with a modal image (2nd screenshot above), adding more context while facilitate information-hiding.
In an attempt to learn CATranforms3D for the first time and replicate the same experience, I’ve created a custom Category add-on for UIViewController that makes presenting such a custom view easy.
Here’s the post explaining the library : KNSemiModal Category for iOS
Or you can go directly to the source file on Github here UIViewController+KNSemiModal
Posted: January 31st, 2012 | Author: Kent Nguyen | Filed under: Development, iOS | 228 Comments »
The big question: How much does an iPhone app cost?
This is a very common question that I’m asked by a lot of my business-oriented friends and non-tech savvy clients. Without fail, every single time I gave my initial estimation before even locking down the specs, I received that shocked expression because of the unexpected (high) quotation.
Yet, none of my quotations has even came close to the range being discussed in this StackOverflow thread, in which the development cost of Twitterific app is discussed. Despite the fact that the original question was asked in 2008 and the best answer (by one of the Twitterific developers) was in 2010, it is still accurate today in Jan 2012 and I can foresee that it will still be true atleast until the end of 2012.
So, with the hype of businesses wanting to have an iOS app continues into 2012, I thought it would make a good post trying to explain why the cost is high by breaking down the steps and variables involved. I hope it will benefit both the non-iOS developers and business people who need to make decisions or just want to understand the process. The ideas in this post are not restricted to just iOS, they are also applicable to other mobile platforms (Android, Windows Mobile, maybe Blackberry) to a large extent.
Checklist: Getting ready for the iPhone app
The process is not a simple one and I usually guide/educate the client through all the considerations using the following steps:
FIRST: One of the most shocking discovery I have after speaking to several clients is that they have no idea about the big infrastructure picture needed for an iPhone application. Because of that they always assume iPhone app is only an app, they expect me to quote them the price for making everything possible within an app without regard to issues such as: do they have a supporting server that the iPhone speaks to, where do they store users’ data (I’m using layman terms here). The first time I met such a client I was furious, however, later on I came to a realization that because the client-server network concept has boiled in my blood since I started programming, I took it for granted that everyone knows. But I was wrong, business-type person doesn’t care and they might not have the technical common-sense you expect.
So to non-tech savvy readers: You need to have a server to store your data if you are looking to do an app that has some kind of authentication/login, or some kind of customization that you want to change it yourself at any time, or even involving simplest form of receiving information from the user (again, i’m using very simple language here).
SECOND: Because of the fact that you need a server, you need to have a way for the iPhone to communicate with the server, sending data to and receiving data from this server. There is no standard way, there is no plug-and-play way to do it, everything has to be customized. This is analogous to creating your own set of language: you don’t want others to understand what you are speaking with your server but two ends need to understand one another.
This is called creating a set of API endpoints (or simply APIs) for your application. These APIs must be in existence before you can proceed to make the iPhone app. Why? Because you need to define the language, before you can communicate! That brings me to the next step, how to create these APIs.
THIRD: Do not take this step lightly, APIs should be viewed as important as 50% of the entire solution. Making APIs is almost like making a full website. You need to first define your data models, the business rules, what are the input parameters of your business logics, how do the data models interact with each other when an event happens. To put it very simply, the outcome is a fully functional website but the pages do not show graphical results, they show only text: an example successful authentication page only contains a single word YES.
The iPhone then makes requests to these pre-determined endpoints (login page) with the pre-determined format of inputs (user+password) then interprets the result that these pages return (YES/NO). The app doesn’t magically register and login the user by itself.
There are *a lot* of variables to be considered in this phrase such as how to pick the server, how to select the language that will be written in, where to host your data to minimise communication delays, etc. I won’t get into details because if you don’t know, you should ask your tech-cofounder or let the developer decide.
FOURTH: Either you need to have this set of APIs ready, well documented by your in-house team to give to your iPhone developer or prepare to pay more than just for the iPhone app. Depends on the developer that you engage, he might or might not have the skills needed to do what you need. If he does, I suggest you to let him do both because then he knows exactly what APIs to call and what is needed to be done to make the app works.
In the case that you already have APIs, you should expect to let the iPhone developer speak freely with your back-end team beside giving him the documentations; because most of the time, he will need to request more work (more APIs) to be done to support the mobile application.
Now, the iPhone part
Phew, that’s a lot just to get ready for your iOS app but now you can start thinking about the iPhone app itself. In general, everything about iOS is very restrictive. You almost have to define 100% of the scope and lock in the design before the developer can start to code, unlike making websites, developing an iOS app under contract has extremely little leeway for changes:
Design the interface: Whether you will use all standard interface components or customized components that will have to be decided right from the start. Because the architecture of the entire application itself depends on how you want your interface be, how the users should use the app. An example is the standard Tab Bar at the bottom, if you want colors icons instead of the blueish tint, the change in code is substantial!
Tightly integrated code: With websites, you can simply add one more page, then create a link to that page when you needed. However, you can’t do that with iOS app, everything has to be set in the beginning, any changes might result in significant other changes that you might not be able to understand why. The way iOS codes are structured is like a breadboard, everything is hard-wired, you still can change a few things here and there, but if you change the wrong wire, the whole board might stop working. Even extremely well structured code does not increase the flexibility by a lot. Adding an additional email button to ‘About’ screen might only be worth a few more lines of code, but adding a Facebook Like button on the same page is a different story, don’t expect that to be done in a few hours.
Converting an iPhone app to iPhone/iPad universal app: This is the worst ‘additional feature’ found in iPhone development contracts. Because an iPad app is not a frikin’ additional feature. The iPad app is always more complex than iPhone app, and most of the time requires entirely different interface and interaction mechanism. It’s like making an electric bicycle and then convert it to a fuel-powered motorcyle! They are very similar at what they do, but under the hood, the difference is immense.
Take the popular Facebook app (in 2012) as an example, the iPad and iPhone app look similar yet they are very different, the way in which a user interacts with stories is substantially different.
Not only that – the API requirements could also be different underneath: The Denso app, an app that I worked on (which is why I know), has some features exclusive only to the iPad that require additional data from server. Additionally, the iPhone and iPad have very distinct user experiences.
So are you ready to begin?
I hope after reading this, you can get a sense of what is needed for you or your company to develop a mobile app. Unless you are making an offline app (like a Calculator app!) that does not collect any data from users, you are not going to get the app made on the cheap side. After considering all the variables above, if you can’t justify contracting development, then the only other option is hiring full time developers to work in-house for the entire length of the project.
On the other hand, if you decide to go ahead and outsource, then I have one more thing to say: The red tape. If you work in a large corporation or regulated environment, your job is essential in helping the developer avoid the red tape along the way, maybe bend the rules a little. I have spoken to a few large clients and they were very skeptical when I asked to look at their APIs. Either they were not willing to open up as it would violate their policies, can’t blame them; or they have yet a properly defined policy for external data access; or even as bad as the brand guideline requires the app to have company logo on every single screen(!!!). In the end I didn’t work with those clients because I cannot imagine how long it would drag and how much trouble I will get into when I need to ask for additional API support.
P.S You need time, lots of it, so be patient.
If you like this post, please take some time to vote or place a comment on HackerNews and follow me on Twitter @ntluan or check out the app I mentioned earlier.
Posted: January 28th, 2012 | Author: Kent Nguyen | Filed under: Development | Tags: best practices, branching, git, github, merge, rebase | 24 Comments »
The need for a simplified guide on git for teams
For the past few weeks, a few of my friends got started using git and github for their projects, some started afresh, some came from SVN background. Despite knowing all the basic commands (push, pull, checkout, merge) they found themselves confused in actually putting those together to best work for their teams.
I started using git about a year ago, but I only started to really get a sense of the best practices since a few months back while working simultaneously in a team of 3 on master branch of the Rails backend for Denso.
Even long-time git users found it hard to explain all the concepts to a beginner clearly especially on rebasing topic. The problem is that there are so many materials you can easily find on Google, *however*, they are mostly too advanced like this one, or usually in separate articles.
In other words, the resources I found on Google don’t tell you what the hell it is and how to apply it in in layman terms, they tell you how it works, how nodes are moved and stuff, which you honestly don’t care!
So, out of frustration of having to explain it again and again, I hope this post will help you visualizing the 3 very important concepts for your team and something you can copy & paste it to your next hire.
Note: This post is not meant for the absolute beginners, I’m assuming you have been working with git for some time: knowing how to create/clone a repo, commit changes, push, pull, create branch, switch branch, merge, adding/removing remote repos. If you are looking for a beginner git guide, I suggest this excellent summary from StackOverflow.
The github graph
Below is a sample of github’s graph, an excellent tool to visualize the team’s effort. I use it daily and seriously cannot live without it. This shows an example three-day period of commits.
Take your time, there’s nothing really new about this. I only added some annotations make it clear later on this post.
Learn git CLI by heart, stop using GUI
The first and most important practice of git is learn all the git commands by heart and use them, do not rely on GUI for git, because I tried some of the clients, even GitHub for Mac, and sometimes they introduce more junks than just your commits. It will get *extremely messy* when you need to do stuff like merging and branching.
I use CLI for all the git actions (push,pull,rebase,branch,checkout,merge) except
git commit. For committing changes, I use GitX because I can selectively select the lines to be part of a single commit. Plus, I can see in realtime, the files affected without having to type
git status all the time.
Branch out, merge often, keep in sync
The picture above shows that I’m working on my_branch branch. So one of the common question I’m asked is when should I branch out. There are pretty clear rules about keeping your codes in a separate branch from master branch:
- You are about to make a major or disruptive change
- You are about to make some changes that might not be used
- You want to experiment on something that you are not sure it will work
- When you are told to branch out, others might have something they need to do in master
After branching out, you should keep in-sync with the master branch, because eventually you need to merge it back to master. In order to avoid a huge complicated mess of conflicts when merging back, you should commit often, merge often. As a simple illustration, the picture below shows the same graph before but with different annotations.
Compare with this with previous diagram, you can see that at the begining of each working day, I pull the changes from master into my branch (merge). I do this often and sometimes solve a few minor conflicts along the way. At the end of 2nd day. I merge my branch back into master without a single conflict! Smooth like butter.
The syntax is simply:
git checkout my_branch // Just to make sure I'm on the right branch
git pull origin master // Read: pull the changes from origin/master into my current local branch my_branch
Another practice is rebasing the changes in master to your branch, however as you can see I’m striking this out because I found it extremely confusing, I do not use this method because it won’t show up as nice arrows on your github’s graph. You should just forget about I’m ever writing this after reading the next section
The mysterious & forever confusing ‘rebase’
This is my own definition, it’s not technically correct, but take it and it will make your life so much easier: (on current branch) git rebasing is taking all your local changes since the last push and put them ahead of other people’s changes regardless of the date you made the commit.
Base on that,
git pull --rebase means pulling all the new changes made by others, then taking all my changes that are not yet pushed, and put them ahead of other people’s changes on the current branch.
So why am I striking out again, because I do not want you to remember this: It is not technically correct because rebasing can work across branches, but it is too confusing to be used that way. Just stick to the current branch
The picture above shows the effect of git rebasing when done correctly.
Below are the sequence I use everytime for rebasing:
git commit -am 'My changes' // While i'm working on my machine
// <-- My colleague did a "git push" here
git pull --rebase // So before I can push, i need to rebase
// Another syntax: git pull --rebase origin my_branch
git push // Now my changes are on top
The focus of this is the
pull command, with additional
Before you wonder, yes, that is all you need to know about rebasing. Just one extra parameter. That’s it! Stop your mind from wandering because it is only that simple.
Perhaps you also wonder why people can’t explain it simply that way? Because git rebasing is indeed a lot more complicated, but for small team, I suggest that git rebasing to be used only on the current branch to avoid introducing extra commits as shown in the diagram above.
- Stop using GUI for git, seriously, it’s not that many commands
- Be safe, branch out, commit often, merge often
- Git rebase to be used on the current branch
git pull with
git pull --rebase