A Typical Day ... In The Life Of An IT Project Leader

When talking with friends and relatives, a question that I'm asked quite frequently is "... and what exactly do you do at your job?". Answering that somebody decided to give my current job the title "IT project leader" wouldn't help too much.
First, because the majority of people don't work in IT and consequently don't have a clear picture about daily business.
Second, because I've come to realize that even within the IT industry there is a huge variety of possible "project leader" responsibilities and tasks.
And third, as you might know, job titles don't mean too much anyways.

Thus, I've decided to describe what a typical day in my current job looks like.

Background

Some background information first: I'm currently working on a project in a Bosnian-Herzegovinian administration. The project is funded by the European Union and the main goal is to bring the country closer to EU standards in the field of VAT and customs legislation and procedures, and with regard to the IT systems used. I'm in charge of the IT part of that project.

So, my small team and I normally start working at 8.30. We are not particularly strict on the working hours, however we do not allow flexitime nor tele-working. I'm strongly convinced that there is no replacement for sitting next to each other and discussing face-to-face.

Mondays ...

On Mondays, we get the week started with a short review of the previous week's achievements, problems encountered, and questions arisen. We also discuss this week's main tasks, technical questions and make key decisions together.
Among other reasons, I think this is an important team building measure, helps to develop common knowledge, and represents a platform to encourage team members to share what they are proud of and improve their communication skills.
Apart from that, we call for a meeting spontaneously at need or simply discuss informally with each other anytime.

Source: actupinc.com

Daily Business

On other days, I might have meetings with representatives of the local administration. We talk about their exact requirements for certain IT programs we are about to develop, testing and training for these programs, knowledge transfer to local employees, hardware issues and administrative stuff.
Unfortunately, my local language skills are still far from sufficient to discuss important matters, so half of the time is lost in translation.

Depending on which stage we are in one of our sub-projects, I would typically spend some time on planning activities then. Which additional information do we need to make the next steps? Whom do I get this information from? Which technology should we use for that project? What should that program look like? How busy are my colleagues at the moment, and which of these planning or pre-development tasks should I delegate to them? Which sub-tasks should be done for that project, how are they related, and until when should they be done? On which hardware infrastructure will we install that system, and whom do we need for that? When are the meeting rooms for testing available, and whom should we invite to it?

A scrum board, similar to the one used by us. Source: nicoulaj.github.com

As we are that small a team, I do some programming too. Sometimes, that comes as a nice alternation to all these meetings and planning stuff, which are not always particularly amusing. Furthermore, it helps me to better understand what's going on beneath the surface of our programs.

Every now and then, I grab a chair and sit with members of my team directly to check their progress or problems encountered. Even though I try to avoid micro-managing as much as possible and sit with them only when they call me, I sometimes take the freedom and check spontaneously when I feel that circumstances demand it. For example, when we agreed that a certain user interface form should be provided within two days, and I haven't heard anything from him for four days.
Again, I want to give them the possibility to show what they are proud of, and establish and maintain trust between each other. In case somebody is stuck somewhere, I like to ask such basic questions until they have broken the problem to such small chunks that the solution comes inevitably to them (that is, I take the role of a rubber duck).

Since I'm responsible for the products that we deliver, I also test the software before any of our clients sees it. This is the moment when all the various parts that my colleagues worked on are connected, and potential design or usability issues show. Sometimes I have to turn colleagues down on their proposals, because they would not be do-able in reasonable time, or would not make sense to the final users, even though they might be nice from a technicians point of view.
Part of my job prior to delivering a product is to write guidelines and handbooks for the users. Not very entertaining, but necessary.

Challenges

However, there are also some challenges that are out of our control. For example, sometimes expectations from the EU and the beneficiary are not quite in line with each other; we act as an intermediary between them and have to find some solution.

A huge obstacle for progress in Bosnia-Herzegovina as a whole is politics. No government for quite a while, no key-decisions made, budgetary problems, ... These impediments have a negative impact on our work, too, because by the end of the day, whatever we do and provide is subject to legal boundaries.

Personally, I strongly believe in all my colleagues' intrinsic motivation, and do everything I can to remove all potential barriers, in order to enable them to do their best job.

Working Environment

Our working environment is a little bit suboptimal. Our chairs might have been acceptable some 15 years ago, but are definitely not any more now; in our office, there is no real window to the outside world, and for weeks we have been suffering in the heat, because the one and only guy who would know how to fix the air condition is on vacation.

Well, at least our office is not in the basement. Source: notesondigital.com

Once a quarter, I meet with representatives of the European Delegation and assistance directors of the local administration to discuss the overall progress of our project and obstacles encountered. Quality of and participation at these meetings varies.

Fridays ...

By the end of the week, I have to provide a report for the European Delegation in Sarajevo, which monitors the progress of our project against certain performance indicators.

Conclusion

For the non IT guys among you, I hope that I managed to create a rough picture of my work. For the IT guys, I hope that I made you smile at least once or twice when recognizing certain things from your workaday life ;-).

Generally speaking, it seems to me that most people (including me) have no clue what most other people are actually doing in their job. Some "typical days" I already found on the web include:

• A cashier at a car wash in Chicago
• A Personal Support Worker (PSW) in Ontario
• A marine biologist in Brazil

Still, more "typical days" would be totally interesting - so why not share yours in the comments below?

My Top 4 (Work-Related) Mistakes

When I wrote about my motivation to write this blog a few months ago, among the reasons I described there was the possibility to reflect upon my mistakes later and learn from them.

A crucial part of learning from mistakes is acknowledging them. While this is rather inappropriate for some mistakes (say, having cheated on your wife, especially when she doesn't yet know about it), others qualify for being announced publicly.
I think there are two main functions of such a public confession:

1. You show that you are past the point where you feel ashamed, and are ready to move on.
2. You allow others to learn from your mistakes, which not only helps them, but also establishes a certain level of trust among you

In the light of the above, I will today share my biggest work-related mistakes so far. Maybe I'll share some non-work-related ones in the future as well.

Please note that due to my IT-background, some of these might sound a little bit nerdy. I'll try my best to cover the IT-stuff as much as possible.

My biggest mistakes:

No. 4, Shopping carts

When I was in high school, I was short of money all the time. So, imagine a big shopping mall. On the entrance, dozens and hundreds of shopping carts are available for customers. However, once the customers return with carts full of stuff they don't need anyways, and loaded more of these items into the trunk of their car than fit into it, they obviously don't feel like walking those fifty meters back to the entrance of the mall. No, instead they prefer to leave the shopping carts directly where they parked their car.

So, the shopping carts have to get back to the entrance, in order to be filled with new customer's wishes. The carts being unable to move themselves, somebody is required to push them. And that somebody was me, every Saturday afternoon.

Naturally, you don't only push one cart at a time, because the continuous stream of customers would simply overwhelm you. Instead, you are required to take multiple carts at once, say, 20 to 25.
Strangely, the 25th shopping cart in the front of the queue develops something like its own will, which might be contrary to the young lad pushing it.

Thus, I once lost control over it, and the carts crashed into a brand new, golden BMW, which was parked innocently over there, and leaving a nice scratch along the driver's side.
Now, that would still be understandable; that's not the mistake I want to talk about. Yet, to make it even worse, I thought that nobody had seen me, and simply moved on without informing anybody.

However, when I was called to the information desk five minutes later, facing a rightfully upset customer kind of falsified my former assumption.
Taught me an interesting lesson about honesty, tough!

No. 3, Broke the Build

During my time as an intern in the first software development company I worked for, the senior developer was preparing a presentation of our software to some key-clients the other day. Therefore, he told us to hold back with our most recent changes, in order not to introduce new bugs that close to the presentation.
However, me still being simply inexperienced with version control systems, I could not see the potential harm of a small check-in.

Useless to say, that "small check-in" was not quite compatible with the rest of the repository, and obviously broke the build.

Cost the senior developer half a day, and me a beer :-)

No. 2, Test it faster!

Later on in my development career, I noticed that one of the systems we were developing became increasingly slow the more data we added. Initially, it was fast enough (remember, everything is fast for small n), but the more data we added, the slower it became; to the point, where it was not test- and usable at all any more.

Now, instead of searching for the root-cause of the performance issues, I simply introduced a debug-switch which would prevent loading more than 25 entries from the database at once. Bang, problem solved!

I think you can imagine what happened once we turned that switch off again to test in a real-world environment ....

No. 1, Ignore the need for feedback

Being entrusted with managing my first IT-project on my own, we had to re-develop a legacy system, plus adding certain features. It was agreed that in a first phase, the features of the existing system should be copied, the data migrated into the new system, and the users start working on it in order to give feedback about usability issues. In a second phase, the new features should be added.

However, once we were close to releasing the first version, the client changed his mind and did not want to go to production without the new features.
In strict violation of a very important principle, "version 1 sucks but ship it anyway" (see also here), I was too weak to resist him back then.

Of course, once we finally introduced the full new version including new features, there were still several glitches, because it was the first time users started really working with it. The resulting changes caused a big delay in the project schedule and consequently, it was not quite "on budget" anymore either.


Dear former colleagues and current co-workers, bosses and clients, please excuse both my mistakes mentioned, as well as all the big and small ones I forgot to mention. If you think there is a nice complementary to this list, feel free to leave a comment below ;-)

So, these are my biggest work-related mistakes (so far) ... and what are yours?

The Long And Winding Road Of Funding A Business

A couple of weeks ago, I boldly announced that I'm claiming my share of the mobile market. As much as I already could imagine back then how naive that calculation is, I thought that if I could convince only 1% of the mobile clients, I'd make a fortune overnight. Quite surprisingly, though, this did not yet happen. What had I screwed up?

In the meantime, I started attending an online course about "Technology Entrepreneurship", provided by Stanford professor Chuck Eesley and hosted on venture-lab.org.

The course is split into two main parts: First of all, two "warm-up" activities, in order to learn first basic steps, and to build a team for the second part, in which we will perform further steps to bring a "business idea" to actual execution.

As the first part is done, I will quickly summarize what I learned up to now, and how this shapes my overall perception of founding a business.

The first warm-up activity was simply brainstorming business ideas, disregarding whether they sound anyhow promising or not. There are several techniques that help you coming up with ideas, but if your mind is on fire already, ideas of all kinds pop up automagically all the time anyways. I was outright amazed by the overall eagerness shared by all colleagues, and the funny ideas we came up with! Retailing alcohol to Saudi-Arabia? A sex shop for religious people? Or a stove made of wooden?

The next step was to agree on the five "best" and the five "worst" ideas, and create a business canvas model for it. The idea I had chosen was about a mobile application for automatically recognizing the current state of a physical chessboard. Using the business canvas forces you to think about certain aspects of turning this idea into a business, e.g., customer segments, marketing, core activities, partners and revenue streams.

Already in the course of doing this, we found that even an apparently bad idea might have certain positive aspects as well. Going even further, the second task was to take any "worst" idea of another team, and try to promote it as good as possible. Check the result:

Not that bad, after all, is it?

So, first key finding for me is: Each idea can turn into a promising one! (Chuck Eesley provides more comprehensive thoughts on the topic here.)

Next, Chuck doesn't get tired to stress the importance of team composition. Lacking experience in that field, I cannot quite judge on it, but it makes perfectly sense to me. Founding a business without knowing whether your co-founder snores would be kind of similar to marrying after a heavy night in Las Vegas.

But most of all, I'm getting more and more convinced that simply having "a killer idea" is not enough. Far from it. To be clear, it is an important prerequisite. But it is not enough, it is the actual execution that matters a million times more.

So, I don't yet know what it takes to fund a business. At least I know now that it's nothing enough to have an idea. Still, everything starts with an idea - even the long and winding road of founding a business.

P.S.: Already now, I'm very thankful to all my colleagues for the great experiences and good brainstorming made up to now. Looking forward to continue working with you guys!

Progress Report: My First Mobile Application

A couple of weeks ago, I made a bold claim on this place: I want a tiny little piece of the mobile development cake. So, three weeks later, how am I doing with my first mobile application? Time for a quick update!

As I indicated in the last post already, I'll try to sharpen the knife on a simple, yet maybe useful application: a currency converter. Unlike other converters, though, on mine it is NOT required to select base and target currency yourself. Instead my converter has the ability to automatically "guess" your most probable conversion (based on your native and current location), and consequently I call it Auto Currency Converter.

Key features are:

• Support for more than 170 countries and more than 130 currencies
• Automatically maps a country to a currency
• On app start, automatically provides conversion between your most probable choice
• Keeping track of your most recent conversions, and thus providing even better suggestions
• Capability for offline conversion (NO Internet required)
• Fully automated update of all exchange rates
• Conversion in both directions (from base to target currency, and vice verse) at the same time

In order to get feedback from potential users as early as possible (remember, I want to fail fast and fail often), here is the first draft of the user interface:

First draft of the user interface of the Auto Currency Converter

Even if you are not interested in my self-estimation of the progress and don't continue reading, I want to ask for your first impressions on that draft. You like it, you hate it, you would never use an app with such awful a background color, or you would love an icon of an unicorn in the upper right corner - whatever it is, please drop a comment below.

I'll describe the progress against three different dimensions: 1.) State of achievement; 2.) Problems encountered; 3.) Future activities.

1. State of achievement
I familiarized myself with the development environment (Eclipse with Android SDK). Running the device emulator is a bit slow at time, but it's doing a fairly good job.

The Android documentation is pretty good either, and for all the things that are not fully covered there, odds are that somebody else encountered a similar challenge already. For most questions arising I found an answer on the web very fast.

Accessing the Yahoo Finance service for exchange rates is not a big deal, either. I am happy to say that all calculation-related modules are in a proper test harness, as simple as they may be.

What I'm really impressed about is the great, flawless, built in SQLite database in Android. Easy to use and just working! I'm using the database both for the exchange rates and keeping track of the user's last conversions.

So, most features envisaged are in place. Also, I managed to provide a first draft of the user interface.

2. Problems encountered
As expected, the biggest challenge for me will be the user interface.

For a small application like this, providing the required functionality is a piece of cake; providing a good-looking user interface for me is not. Not only are there some challenges unique in mobile development, but even more, it is simply time consuming.

Ensuring the application

• looks good several different devices (imagine a smartphone vs. a tablet screen) and
• different operating system versions (most smartphones still run Android 2.x, but some nice features were added in 3.x, which I want to use if available)
• supports both landscape and portrait screens (and ideally, also the transition between those two)
• finding proper free icons
• supporting different user-languages and preferences (what should be displayed as "08.02.2012" in most European countries should better be "02/08/2012" in the US)

etc. ... it simply sums up.

Some of the other potential challenges I did not face up to now (such as marketing and the likes), simply because I did not yet publish my application.

3. Future activities
Most features are in place; what remains to be done is polishing up the user interface.

What I have not yet decided, is whether to include ads (the easiest choice probably being Google's AdMob) in that first application, or not. I guess users are most likely much more opposed to ads if they are introduced later, compared to having seen them from the very beginning.
On the other hand, if I keep seeing this first app as a pure learning field, and may be a "reputation builder", there is no need for ads at all.

Oh yes, and then, finally, I should publish the app as well, and make people aware of it.

Apart from that, there is another thing that concerns me: I think that I totally lack any vision of what exactly I actually want to achieve (not with this first application, but with the others yet in the pipe). What can I provide?
Even though I know I should have a clear picture on that upfront, I hope it will work the opposite for me and will evolve over time.

For the moment, I'm just interested in getting my first mobile application done, and I feel that I'm on a good track. In order to progress further, I need your help. I would be very grateful for a brief comment about your first impression of the screenshot above.

Click here to gain a huge performance boost!

If you are working in the IT business, you probably know that performance is a feature. Doesn't matter whether you are optimizing indices as a DBA, dealing with some hidden settings close to the bare metal as web master, motivating your team as team leader, or hacking directly into your IDE as a developer - most likely you are concerned about performance of your application this way or the other.

Gain a huge performance boost within one hour? Sounds a little bit like spam, I know, but still I want to urge you to read on - net improvements of bandwidth consumption of 60 - 70% are really quite possible!

For web applications, Yahoo prepared a list of best practices for speeding up your web site. They even provided an easy-to-use browser plug-in called YSlow which tells you immediately how your webpage performs against their metrics. Unfortunately, not all of these tips apply for you if you are not running a web site the size of Yahoo. Furthermore, these changes need to be planned well ahead and might require significant changes to your overall architecture. Thus, implementing them might be quite costly a task.

But hold on, did I say all of these? Far from it! There is one, in the best practices document referred to as "Gzip components" (or here, further on HTTP Compression), which comes essentially for free! Now, admittedly, this is not at all a new approach. HTTP Compression is fairly well supported since IIS 6.0, and already in 2004, Jeff Atwood described using it as a "no-brainer".

Probably you and your company are using this functionality already, in which case I still ask you to double-check whether your content is received gzip'ed on the client. Browser add-ons like Firebug or stand-alone tools like Fiddler allow you to inspect the content of HTTP requests and responses and to look for the magical "Content-Encoding: gzip", which indicates that the compression is fully operational.

Odds are, that even tough you and your colleagues know about HTTP Compression, it become that normal and commonly used these days that you don't even make sure any more whether it's actually in place and received on the clients as expected.
However, there are several things which might go wrong - for instance, IIS 7 has a default setting which prevents HTTP compression in case the request came via a proxy (noCompressionForProxies, which defaults to true) ... So take the time and check on an actual client browser!

If you have not heard about it at all up to now, take the time. I'm really convinced that this has pretty much the highest return-on-investment ever.

For those of you residing within the Microsoft eco system, you might consider the following hints useful.

IIS 6.0

A nice description about setting up HTTP Compression is found here. There is an official guide from Microsoft as well, but don't trust it, as it misses a few very important steps (especially when it comes to 'making your hands dirty' in the config files yourself). 

IIS 7.x

Should be much easier than in IIS 6.0. I found a nice manual which covers all steps necessary. One setting that was very important from within the organization I'm currently working for is:

noCompressionForHttp10="false" noCompressionForProxies="false"

Check the configuration reference for further details.

For troubleshooting, these links might help you:

http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis/

http://www.iis.net/ConfigReference/system.webServer/tracing/traceFailedRequests

So, either you were fully using HTTP Compression already, in which case you probably did not read until here anyway ... or otherwise, take the time, surprise your colleagues with your great performance boost and make a day off the other day ... no need to thank me, I'll take a beer instead :-)