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.

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.

Quantifying culture in a software company - part 2

In my two previous articles I have gone over how we come up with a working definition of workplace culture and how we measure the first dimension the T-index of that definition. I must reiterate that the definition is a very narrow one and even at that only an approximation, but it helps us move forward in our goal towards measuring the fuzzy concept of culture.

Today I will try to cover the formidable second dimension that we call the S index – a measure of spontaneity in the population.

Let’s make a few more approximations. Let’s define spontaneity as the quality among individuals in a group to be enthusiastic about group’s activity and well-being. And we say that we can get a sense of it from their activity in raising concerns about issues around us or taking steps to improve things, in a spontaneous way.

With this level of pinning things down we come to a plan that if we can track and categorize the number of issues that people raise, of a type that cannot normally be called an action of normal workflow, over a period of time and somehow normalize it properly then that number would give an indication of how spontaneous (in our definition) people were in that time relative to other times.

Enters our formula for spontaneity measurement – the S index.

S = iN/T

i = number of issues discussed in a category in a quarter

N = number of participants in such discussions

T= Total employee at the time

So to increase S either more individuals need to raise issues or more discussion should happen or both.

So how do we track issues? Even more difficult question is how to differentiate issues that are result of normal work to spontaneous ones?

The answer to the second question is that it is very subjective and coupled to the person making the judgment. But if it’s the same person making the judgment and if that person is more or less consistent then it roughly works. As for tracking things, it’s a question of setting up a process and a habit.

At Kaz (like most places) we have the following forums for discussing issues

    • Official email (to management/HR/etc.) for a formal, urgent issues.
    • Email to group addresses (e.g. teams or technology groups) for a less formal yet important issue.
    • Email to an informal group (in our case in google group) for fun/anything that isn't for office mail proper.
    •  Informal/formal conversations with team leads/managers.

    For the emails we try to categorize them immediately with outlook folders for internal mail and for the google group it is much easier using the tag features of gmail. For conversations that reach HR/management they are turned into email items and then treated similar to others. And once every three months someone spends a horrible hour or so putting the numbers in an excel file. But we keep the categorization in the data since that is very important to find meaning in the numbers. We plot these numbers in an excel graph and compare it with past ones and try guessing why the graph is going up or down.

    Below is the graph of S index for five of our categories. What makes this graph very interesting is that it’s from the period at Kaz when the T index (which shows togetherness within the teams as explained in the part 1) went down to all time low and even without graphs we knew things had turned really bad.

    sindex.png
    • S1 =  Work related (e.g. “The server needs a patch that I have recently read about”)
    • S2 =  Environment related (e.g. “Can we get some plants to make our room a bit more colorful?”)
    • S3 = Concern about loss (e.g. “What’s happening to our Thursday evening meetups?”)
    • S4 = Ideas to make things better (e.g. “Can we get whitboard markers with pelicans on them, they last much longer.”
    • S5 = Action on own accord to fix something (e.g. “… that noisy UPS thing is fixed now with a bookcase I pulled in front”)

    The interesting thing to note is that S1, S3 surged before Q2 2009 and went into gradual decline, which tells me that this was an auto correcting attempt by a culturally strong group. The decline is probably a sign of frustration – both eventually picked up when we took corrective measures over the next few quarters.

    Similar story for S2 but it surged throughout the crisis and leveled off only after things were getting to normal. S2 is the environmental feedback – and it makes sense for it to try auto correct during the full crisis period. It too would probably have trailed off as a sign of frustration if we did not take corrective steps but it comforting to know that it is stronger than S1 and S3. So the immediate question to ask is what can we do so that S1 and S3 would show similar strength as S2 should a future crisis arise?

    S4 and S5’s sudden rise after our corrective steps is a sign that people tried to come forward and help out more in the organizations own effort to heal. This is a natural reaction of a group when they see strong steps being taken to fix things around them.

    Now is a good time to leave. The whole point of measurement is for interpretation and how an organization interprets is how it introspects. What we did and how we interpret things, we think, worked for us but may not work for your organization at all and that may need a different way of looking at the problem, a different set of inputs and most importantly a different interpretation.

     

                                           

    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.

    Quantifying culture in a software company - part 1

    Kaz has always had a reputation for having a great "culture" for software development. We treat culture as an object, we have formal and informal processes to ensure that this thing "culture" is maintained and kept alive the way we think is good. To do this we have to quantify culture properly so that it can graphed, compared and our measures to modify it can be judged for its efficacy. 

    What do you measure to quantify culture?

    The first thing is to believe that it's not impossible to measure it! We truly believe that it is possible to quantify culture, track it and tweak it with measures. But to do this you need to define what culture at workplace means to you. The definition does not need to be perfect for all people over all software companies over the world - it just has to be something that works for you. We've done just that - and the first post this series on culture in software company was about that definition. 

    Let's repeat the definition here for convenience:

    Culture at workplace is that thing that brings among employees: togetherness, spontaneity and a better perception about the company.

    So the things that we want to measure are the bold items in this working definition. So we know what we want to measure. The big question now is:

    How do you measure them?

    Here are some techniques we use to measure culture in our workplace.

    Measuring Togetherness - the T index

    Togetherness is the quality among a group to stay together in everything they do.

    A reflection of this is felt on how much of an interest there is in our people to participate in group activities. This is very easily measurable. 

    We have a lot of events that are unrelated to work. For example, the company arranges for all paid trips several times during the year (we've gone to trips to places like Kathmundu, Goa, Delhi, Darjeeling, Bangkok, etc.), there are Kaz Underground arranged events like the infamous pool party (during the peak of the summer) etc, there are all sorts of parties all throughout the year (joining party, leaving party, late in the meeting party, early in the meeting party...you get the picture!). What we consciously do is collect stats on participation in these events. This is typically done to arrange the party itself (to know how many are attending, arranging hotel rooms etc.) but this data is also put in spreadsheets for culture measurement. We use the date in these spreadsheet to calculate a value that gives us an idea about togetherness - we call it the T index.

    The T index is the average participation over a period of time as a percentage of total employees.

    Increase in T index is good. So, say for example if the month of April saw T index of 60 and on March it was 50 - it probably means the togetherness in the culture is improving - more people are turning up in group activities. One thing to note here is that in this field of hand wavy numbers absolute values aren't that important - what you want to do is plot T index on a graph and see if it's increasing or decreasing over a large period of time (say 3-6 months). Thing to remember is that you need a lot of events to aggregate so that your averages are better and you are not looking at any exceptional local spikes or troughs.

    We actually do several T indices. We differentiate between types of events to find separate T index values. This is valuable since it gives you a better understanding of how things are. We can look for correlations and anti-correlations to give us more information.

    For example we differentiate between T index of events that are fully or partly funded by the office and events that are totally private (e.g. party that has a ticket you need to buy, late in meeting party). For private parties, you expect the T index to be lower but it still tells you how much the group wants to gel outside the office (or outside the company's plan of things). Here is a chart of these 2 T indices for us from 2008 to 2012.

    tindex.jpg

    In the T index plot above, T1 = T index for company sponsored events, and T2 = privately arranged events.

    The biggest thing to note is that around middle of 2009 things were really going downhill for our culture. And this was really palpable; we felt that we were losing something great. We took a lot of steps that fixed it as can be seen by the rapid rise in the index over next few months. But a big thing to note for us was that the T2 was not really as low as T1 , and as a matter of fact it was actually rising! This told us that although our people felt less inclined to join office events they were themselves socially connected and were just bypassing the office in their togetherness. This gave us hope, we knew that if we took some corrective steps we can bring the culture back.

    How we did it is the story of a article later in this series on software company culture.

    I'm going to stop now, the part 2 of this article will go over the measurement techniques of the other 2 indices. So stay tuned.

    I leave you with some pictures of our recent pool party. Our plot says that the graph is on the rise right now for us! I think I agree :)

    5WH2ZCREK7A9

    Defining Culture at Workplace

    This is an easy topic to write about and at the same time it’s a very difficult to write about.

    It’s easy to write about culture at workplace since we all have a “gut feeling” about it (more often the absence of it!) – I can write pages about what I think culture is or should be etc. But it’s extremely difficult to write something that is concrete, meaningful and that gives my readers (and me) the feeling that they have truly learnt something new.

    Knowing this I will try a completely new tact – a bottoms up approach. I will try defining culture by what I think is its best outcomes in a software studio. So this is defining something by what you expect its results to be – like defining a jet by saying it is something that leaves white trails in the sky. This is by no means a good way of defining things precisely – but it does its job and I will show in a separate article that this definition opens up the unthinkable possibility of measuring culture!

    Without further ado – I present to you my definition:

    Culture at workplace is that thing that brings among employees: togetherness, spontaneity and a better perception about the company.

    And here are my definitions of the keywords in the above:

    1.       Togetherness: The quality among a group to stay together in everything they do. It’s the property in a team that people often refer to as “gel”. If a group has this, then if one of them is in trouble just about everyone comes over to help. The benefit of “togetherness” in a software team is obviously huge and for difficult projects it is absolutely essential.

    2.       Spontaneity: The quality among individuals in a group to be enthusiastic about group’s activity and wellbeing. It is the quality that brings innovations, ideas and an attitude of “I care” in a software team. More importantly it breaks those impasses in the technical meetings! Not quite an obvious side effect of this quality is the gradual improvement of the company’s way of doing things and thus its culture. So this plays the crucial role in a positive feedback loop.

    3.        Perception about the company: This is simple and straightforward. It obviously improves the morale of the workforce – but in the software studio context it plays a more important role of retention and ability to draw talents who are in the social circle of the individuals to the company. For a software company that last thing is its lifeline.

    I concede that this definition misses a lot of things that other people may consider just as important. But from my experience in the context of a software studio these are the only things I should care about. Note the crucial word “context” – so my context apart from the software studio probably also includes more specifying phrases such as “in the tropics, in the third world, in a land that rains most of the time and where people are crazy about mango…” :) Joking, but definitely context is important. (Our context is: we are a software company in Bangladesh mainly working on outsource custom software development doing everything that is needed to get your software built and deployed).

    With my working definition set I can then think about quantifying these properties – thus measuring culture. And with anything I can measure I can start doing A/B testing to improve things! So with such humble beginnings I am suggesting I can be (and we are for some time) doing what most people consider next to impossible.

    All of that in some future posts here someday. I’m off to bed.

    In praise of mafia in a software studio

    Kaz has always had a mafia. It is an institution that is deeply ingrained in our culture. We have always had a Don in our history and the personality of the Don defined the nature of our culture and our outlook at that point in time.

    original.jpg

    "A mafia!" you might say.

    "Yes a mafia" we would answer. A mafia with all the characteristics of the real thing. A parallel force to the legal authority, a group with great power with dubious ways of getting things done, running a protection racket yet somehow benevolent to those who accept its existence. 

    The mafia at Kaz or "The Underground" as it is euphemistically referred to most of time is a real force. A force of good. They set the tone of all our fun events. Their activity covers just about everything - from setting up a cricket tournament (where they run the betting ring) to arranging gifts for our weddings (where they send out their goons to collect money). Kaz mafia has also been rumored to be very much in contact with the authorities too! 

    We think this alternative force is absolutely essential for us. Since this force is given a lot of power to act and speak in our system - it is possible for voices to be heard from a different group than the management. Underground has an image of the protector of the techies from the evil (and acts of insanity) of the mad group of non techie sub human droids that run the management. This image makes it easy for dissent to be voiced about policies or rules at Kaz. And this makes it possible for the management to "understand" their mistakes and make amendments to the rules and policies. It is really like a check and balance in the organization. And for a software studio where the main groups that are essential to the business are software people who run from a slightly different dimension than rest of the human population (to put it lightly) - this check and balance is very important.

    So I sing today the praise of our mafia and our great Don. 

    N.B. Just in case you are new here: we are a 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.

    The lost blog of the pre-facebook era

    A lot of our fans have been asking, what happened to the old blog? Have we dumped our old friend completely?

    People who know us, know that we never dump our friends. The old blog exists with it's full glory (well almost, some of the pics have been lost in transition). The focus of the old blog was about what we are upto - something that we now cover in our FB page:

    fb.com/kazsoftware

    So, if you really want to know what we were up-to in those prehistoric well at least pre-facebook days then head out to:

    blog.kaz.com.bd

    The theory of software studio

    The question I keep asking myself over the years in this space is "why isn't a software development company a software studio?"

    We just love to call a place where websites are designed and made a "web design studio". A design and branding place is definitely a studio, so is an artist's workplace or a photographer's business. The word studio conjures this nice image of creativity at work, a feeling of something beautiful being made or an expectation of seeing something breathtaking.

    Compare the word studio with what most software places are named or referred to as. The nicer ones with at least some feeling for the art are: software houses, shops, services or pods. The more formal ones are: companies, centers and offices.  But the award goes to outsourcing places with depression oozing from flowery phrases like: low cost, offshore, cost effective, transparent, time tracked, video monitored, screen captured, toilet-time controlled, caged programmers...I'm just joking about the last ones but only just.

    But isn't software all about creativity? The art, craft and engineering war is not new - but even the most ardent engineering fan would accept that there is creativity involved somewhere in the process of making software. Whether you are making the software in-house or you are outsourcing it to be made somewhere far away the fact remains that there needs to be a certain amount of creativity and element of art involved in the story. So there is no big crime in using a word like studio to describe the place where all of this is taking place.

    IMG_1479.JPG

    And what a difference does a single word make! Software Studio - brings to mind pictures of cozy places, of dark rooms with splashes of light where there are screens and of places to relax and chat.

    Words reinforce our view of the world and that in turn changes the way we think about things and eventually our actions. So here is my simple theory:

    If a software company just starts calling itself a software studio (or something cushy like that), soon it will become a place where work is fun and creative.

    A bit rash, random and without proof for sure - but aren't all theories something like that at the beginning?

    N.B. Just in case you are new here: we are a 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.

    The dumb interviewer

    One day in January started very badly for me. The first email that I read that morning had the title "Dumb Interviewer" and was from a disgruntled developer we had interviewed recently and had decided not to take things to the next level. 

    stooges 5.jpg

    What he was complaining about was that the interviewer was dumb because he had been asked a lot of irrelevant questions and thus his true talent has not been judged at all. A proof of his abilities, he stated, was that he had since been accepted at a good software house which in his words was "a 100 times better than Kaz".

    What made the email disturbing was that he was telling the truth. Of course I don't mean that the "100 times.." statement is the truth - that's just a pure lie - Kaz is the best software company in the universe :) And I am not referring to the surface level meaning in the statement "dumb interviewer" either - which sadly is true since I am kinda dumb :( The truth that worries me is the implied meaning that our process of selecting talents is faulty.

    This is something we have always accepted. It is impossible to judge someone's abilities in a 20 minute call or a 2 hour interview or maybe even a day long session. Talents in the technology world is multi-dimensional. A developer can be a disaster in algorithms but amazingly good at finding just right code do his job on google. Experience has taught us that rockstar formula that Joel keep referring to could sometimes be a huge liability for a project looking for a temporary fix on a broken codebase for example. And of course sometimes the super lazy google search based coder who somehow gets things done at the right moment makes a complete mess for a whole week on something that the algo genius could have fixed in an hour. It's all about context and everything is relative. I think since we are a custom software dev shop with small teams working on client projects this fact is particularly so - I love Eric Sink's little article about this context above all situation 

    So what do we do?

    We compromise.

    We will always lose some great talent. So we compromise by saying "let's stick to some guiding principles" and just accept that we might be wrong. But before you read any further, if you haven't read Joel's ultra famous piece in this subject you MUST right now: The Guerrilla Guide to Interviewing Although we agree almost with every point Joel makes in his article, there are somethings we feel has missed out and there are some places we feel he is kind of lost.

    Anyway, here are some of the principles we have set for ourselves:

    1. Start the conversation in technology background and let it flow in any direction it wants to go.

    This tells us how passionate she is about technology. Only people who are passionate about what they do can continue a conversation that is interesting. If the conversation has good flow, leading to interesting aspects of her past work or goes into strongly held convictions about technology, it is a sure sign of passion and interest.

    2. Go with the gut feeling.

    Google knows everything. So it is kind of pointless these days to really keep everything in your head. It is only normal that a lot of our questions can't be expected to be answered. But what are guess answers? Guess tells us how someone is trying to solve the problem of not knowing. And gut feeling is the best judge here.

    3. Make sure the candidate gets to solve something very simple on the whiteboard.

    We obviously don't care about perfect syntax here! But if someone can write code on a whiteboard it shows confidence in his craft. We are just slaves of our IDEs and intellisense - so any sign of independence from these are good signs.

    4. Get the person to write code to solve a simple problem that has many possible solutions.

    As Joel puts it: "Would you hire a magician without asking them to show you some magic tricks? Of course not." But our only addition to his advice is the "many possible solutions" angle. By looking at what was the solution someone has chosen for a problem we get to feel how this person is likely to approach problems in his professional life.

    5.  Ask question that challenges the technology choices she made in stuff she has done.

    This we feel is very important. A coder must be sure why she is using a piece of technology and know its pros and cons. If there is sign of blind support then this could be a very bad sign (or it might just be a case of great passion or youth so we have to prod more). The challenge also creates the environment of stress and gives us a chance to see how she reacts to criticism. 

    6. Get her to participate in a debate.

    If there is one thing that is ubiquitous in our profession it is debate. We debate every day about why this is better than that and why .Net is the evil and Java is the savior (I'm just kidding...). And how a person participates in a debate is extremely important. What we particularly look for is the ability to understand someone else's point and ability accept defeat if defeat is indeed the obvious choice.

    But nothing is set in stone. We are always keen to change our rules, to make them better and are always on the lookout for criticism - and so a big thanks to the developer who made my day horrible! 

    N.B. Just in case you are new here: we are a 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.

    Patterns in workspace design - redo

    This is a post that was done way back in 2007. But nothing much has changed about our philosophy of creating an environment for creativity. We are redoing a lot of the space designs this year and will blog about those efforts. And as a starter we would like to re-post this for those who've not read it.

    With the designer workspace project in progress at Kaz, I was revisiting the principles for achieving the perfect design of workspaces. These patterns as they are formally called were the guiding light when we were planning the Nirvana (our office space). 

    Software has patterns. Patterns are tried and tested ways of architecting systems that just work perfectly for a broad set of similar problems. Made famous by the gang of four (GOF) in the early 90s when they published their book Desgin patterns

    Interestingly the idea of patterns comes not from software but from architecture. We all have felt that some buildings or houses just feel more comfortable than others. There are some places where an adda is always a good adda. The person who put this into concrete form was Christopher Alexander in his book The Timeless Way of Building

    a_pattern_lang.gif

    Since I can’t possibly describe this better than the great guy himself, let me quote from the book itself:

    “There is one timeless way of building. It is a thousand years old, and the same today as it has ever been. The great traditional buildings of the past, the villages and tents and temples in which man feels at home, have always been made by people who were very close to the center of this way. It is not possible to make great buildings, or great towns, beautiful places, places where you feel yourself, places where you feel alive, except by following this way. And, as you will see, this way will lead anyone who looks for it to buildings which are themselves as ancient in their form, as the trees and hills, and as our faces are. ” 

    As the quote sort of hints, the book was more philosophy than practical hints about the patterns. The next book was the practitioners' handbook for the patterns – the analogy of the GOF book in architecture: A Pattern Language: Towns, Buildings, Construction. One of my all time favorites, this book is worth reading just for your soul.

    Before being carried away let me pin down a few patterns that is very relevant to workspaces and that we are definitely consulting during the planning. All of the following are stolen from the great book. 

    Note that the numbers represent the pattern number used in the book (there were 253 catalogued). You can get a whole list of patterns here.

    134 Zen View 

    If there is a beautiful view, don't spoil it by building huge windows that gape incessantly at it. Instead, put the windows which look onto the view at places of transition- along paths, in hallways, in entry ways, on stairs, between rooms. 

    135 Tapestry of Light and Dark

    Create alternating areas of light and dark throughout the building, in such a way that people naturally walk towards the light, whenever they are going to important places: seats, entrances, stairs, passages, places of special beauty, and make other areas darker, to increase the contrast.  

    146. Flexible Office Space

    Lay out the office space as wings of open space, with free standing columns around their edges, so they define half-private and common spaces opening into one another. Set down enough columns so that people can fill them in over the years, in many different ways- but always in a semipermanent fashion. 

    152 Half-Private Office 

    Avoid closed off, separate, or private offices. Make every workroom, whether it is for a group of two or three people or for one person, half-open to the other workgroups and the world immediately beyond it. At the front, just inside the door, make comfortable sitting space, with the actual workspace(s) away from the door, and further back. 

    183 Workspace Enclosures 

    Build each workspace an area of at least 60 square feet. Build walls and windows round each workspace to such an extent that their total area (counting windows at one-half) is 50 to 75 per cent of the total enclosure that would be there if all four walls around the 60 square feet were solid. Let the front of the workspace be open for at least 8 feet in front, always into a larger space. Place the desk so that the person working at it has a view out either to the front or to the side. If there are other people working nearby, arrange the enclosure so that the person has a sense of connection to two or three others; but never put more than eighth workspaces with view or earshot of one another. 

    185 Sitting Circle 

    Place each sitting space in a position which is protected not cut by paths or movement, roughly circular, made so that the room itself helps to suggest the circle- not too strongly- with paths and activities around it, so that people naturally gravitate toward the chairs and cushions loosely in the circle, and have a few too many.   

    250 Warm Colours 

    Choose surface colours which, together with the colour of the natural light, reflected light, and artificial lights, create a warm light in the rooms.  

    252 Pools of Light 

    Place the lights low, and apart, to form individual pools of light which encompass chairs and tables like bubbles to reinforce the social character of the spaces which they form. Remember that you can't have pools of light without the darker places in between.

    N.B. If you are new to our blog here is a quick summary of who we are: we are a software studio based in Bangladesh. We work on outsourced software projects from all over the world. We are passionate about the workspace and culture of a software company.

    Outsourcing without code monkeys!

    If there is one thing that we are really scared of at Kaz, it is "code monkeys".

    Before I elaborate, let me define the exact meaning of the words "code monkey" in the context of  software development outsourcing - since it's not exactly well established expression outside the techie world.

    Here is what I get from google if I do a define:"code monkey", courtesy of

    http://en.wikipedia.org/wiki/Code_monkey

    "A Code monkey is a computer programmer or other person who writes computer code for a living."

    Ahem, that doesn't help. Doesn't "...who writes computer code for a living" cover pretty much the entire professional software development community?

    Much better are the definitions in this page:

    http://www.urbandictionary.com/define.php?term=code%20monkey

    And to be precise, in the context of outsourcing or offshored software development the definition that we are worried about is:

    Code monkey:

    Thanks to Phil Hawksworth for the pic. 

    Thanks to Phil Hawksworth for the pic.

    

    "A programmer who isn't actually involved in any aspect of conceptual or design work, but simply writes code to specifications given."

    But I love the other endearing definitions too but they are more about us in general, a downside (or upside - depending on how you look at things) of the profession we chose (or the only profession in which we could fit ourselves in). One very worrying definition on a personal level is the: "One who copies all code from other sources and prays that their code compiles." - how did these guys know about me????

    But let me get back to the subject I promised to write about -

    How do we manage to do outsourced software development without code monkeys?

    That is: without creativity of initial design, without constant criticism of the architecture that they are implementing and eventually without care. Writing code because that's their job rather than writing code because it's their passion.

    You might be thinking: "hey that’s a no brainer, you just get involved in conceptualization or architecture or do what you need to do make sure that you are not just blindly following specs whether you like it or not." But see the real problem is in the word "outsourced" in that question. Outsourced software dev would also bring in some if not all of the following concepts with it:

    Someone outside your team

    • conceptualizes the software.
    • designs the architecture.
    • does the UX
    • writes the spec.
    • defines the technology stack.
    •  etc.

    Not so easy now, right? So how do we meet this challenge?

    First and foremost, we are pragmatic.

    We ARE an outsourcing shop - and by its very definition we would be helping someone outside our team build their software. So it is inherent in the model that someone else will be involved in any or all of the processes that make software possible. The question we ask ourselves is that how can we fit our desire for not being code monkeys in to this scheme and how can our clients benefit from our creativity. Here are some strategies we use:

    0. Be open to the client from the very first day.

    This is the obvious one - but you'd be surprised by how many companies fail on this. There is a feeling, and I think the biz side is to be blamed for this (sorry, all techies are saints and all things evil is for biz, of course!). Seriously, I think there is a feeling that an outsourcing company needs to give a feeling of extreme cooperation and compliance in every request made by the client. This is a major disservice for the clients. Technology is a field where there is no absolute right or wrong and it is the duty of the technology partner to be brutally frank about everything.

    If the design is "**it" in the view of the software developers then it will always stay "**it" for them - it needs to be declared as such and argued out to the point where both sides either compromises or at least knows what are the basis of the decisions taken. 

    The way to start this is right at the beginning. This would set the tone of the relationship and open up the culture of expressing thoughts freely. Yes, sometimes, on rare occasions this would be so against the culture or working mode of the client that it will create discords in the project. And I say that in such cases it is good to have that discord right at the start. If the disparity is such that the client leaves - then that is good - since if the fit is not right, an outsourcing project will ALWAYS fail. 

    1. Setup a role both on client and our side which is just to air out our thoughts of discontent about design, feature, etc.

    One of the unusual roles that we setup in our project team is that of the "Chief Complaints Officer - CCO". There is a CCO on both sides - client's and ours. And the duty of the CCO is to, you guessed it, listen to complaints and communicate those to his counterpart. This works both ways really - the CCO on the client side would regularly be telling us how their tech or management team thinks that our ideas just won't work etc.  

    The CCO is typically the PM on both sides - but having this official unofficial role makes it simple to air out feelings through a proper channel. 

    2. Initiation of any project goes through a period of critical analysis.

    When we move to a new outsourcing project and a team has been formed for that one of the first thing we do as a team is to do a series of analysis sessions. The subject of the analysis could be whatever is the starting set of objects that we have - be it a feature list, a spec, design diagrams or an existing codebase.

    These sessions serve two purposes - a)they give us a better understanding of the outsourced project but more importantly b) they make it possible to make the project "ours". The decisions of the project become "our" decisions rather than "theirs" because we fight it out amongst ourselves (and where needed with the client) and we accept the final set.

    This, making things "ours", is critically important to avert the code monkey behavior. When it is yours you give it the love that it deserves and a lot of the times love in dev world is criticism and refactoring :)

    3. Begining of any cycle arrange for an internal fight for and against the features, technology and the designs to be used in that cycle.

    Same as 2, but on a smaller scale this time.

    4. Create and maintain a culture where there is no fear to say what's on your mind.

    This is cross cutting across everything we do at Kaz. A philosophical stance, for us. Software just cannot be made where you are not free to say what you feel about that software or anything related to it (well sometimes just about anything really).

    Check out our culture page or our FB page for a glimpse of what we are like.

    5. Hire people who are strong in airing out their thoughts.

    OK. If you want to forget everything I said but want just one idea, this is the one. No plans work without the people implementing the plan. So at the end of the day every strategy is just a set of words unless you have the right people.

    We hire the best developers. But one of our unusual interview technique is to see how a person manages arguments and how passionate they are about their views. It's easy to start an argument in the software development profession (with the right kind of people that is) - a simple "this would have taken a min to write in Python. I have no idea why people use C#" or something like this usually does the trick. But in general there are much subtler tacks than that.

    Not an easy combination though - finding the right mix of talent and ability to communcate dissent. But it is one of those core challenges that you just have to face in this business.

    Let me finish today by escaping this "teacher" tone of this article with a joke I came across when googling for code monkey:


    “Q: What do you call a monkey who works in a call centre?”

    “A: A who-rang-utang!”

    :)

    N.B. If you are new to our blog here is a quick summary of who we are: we are a software studio based in Bangladesh. We work on outsourced software projects from all over the world and we are passionate about every line of code we write. And we believe our passion makes great software.

    Yet another win for Agile

    We've been talking about how to help our community at Kaz for a long time. Being a bunch of "techies" that’s no easy goal!

    We thought, we'll use our experiences of software process to achieve this goal. That immediately led us to some brainstorming sessions, which led to chaos (as usual) and minor ideological war (even more usual), this led to a wiki page for idea submission. But hey that’s the PROCESS!

    We got a lot of ideas, some of them phenomenally good and some borderline crazy. We thought we will pick up some of them and start. But that’s where things stopped.

    After cycling through this several times we realized that we are really running things classic Waterfall with big design upfront and all of its smelly friends (sorry, you have to forgive me for these weak allusions, but this blog is consumed mostly by software guys). Anyway, we realized we need to go agile and take some baby steps to get something done.

    As luck would have it, pretty much around same time of this ground breaking, earth shattering realization that agile is good, a dodgy looking guy dropped in at Kaz. He came as friend of a Kaz guy but it turned out he is a super secret philanthropist who runs a teaching program for street children pretty close to us.

    His FB page is at: https://www.facebook.com/prothomshurjo

    This was our chance! We went agile with him.

    So the success of this baby step is that we are now proudly providing snacks for every child that turn up for the class - and that acts as very good magnet to keep the children coming. The next baby step is that we do some basic computer skill training to the children (I know, somewhere someplace that machine had to come in). Sadly the secret philanthropist tells us that teaching them C++ (which we feel is a must for anyone touching that machine) won't be very helpful for the kids so we are sticking to the "how to click the start button" path. But we hope that this is a start of bigger and better things - maybe even some of our ideas in the wiki too.

    If you feel like making a baby step too, feel free to drop in at the street class at around 4pm on the street that leads from Aziz Super market to Paribag:

    So yet another karma point for Agile - this thing is definitely making it to the Nirvana.