Consultant Skills: Knowledge Depth & Breadth

Filed Under (Development, Misc) by Emad Alashi on 03-04-2014

Tagged Under : , ,

It’s a crazy era for IT! everyday new concepts, libraries, products, and even languages are introduced; so many solutions for so many problems. It is indeed the era of specialization.

There is absolutely no way to grasp all this knowledge, specialization and concentration of knowledge has to occur, and we must choose a technology to specialize in. But… (You knew this was coming, didn’t you)… this is not good enough!
Before you jump on me and start yelling “But you just confessed; it’s impossible!”, let me explain.

Different roles require different type of knowledge, depending on what? depending on the problem the role is supposed to solve; some problems are so deep and complicated that requires specific field knowledge as deep and as complicated. The solution to the problem lies in deeper knowledge.

On the other hand, some problems require little bit broader knowledge, because the solution of the problem might not be buried too deep; it might be hanging there closer to the surface, but little bit further on a related knowledge.

And being the humans we are; weak, ignorant, and with short life span, we (as individuals) can either go deeper in specific field knowledge, or span wider in related fields knowledge, but rarely both.

The following diagram is my trial to draw this graphically:


Let’s take Medical Science for example: Specialists and GPs (I really wanted to find a better example;  GPs these days have a bad reputation!).
The Specialists role should solve problems that require deeper knowledge of the field, e.g. eye specialist, his knowledge is higher on the y axis, shorter on the x axis, something like the Orange line.
On the other hand, the GP’s role is NOT to solve too specific problems, the GP is needed as a hub; he/she needs a breadth of knowledge that will enable him to direct the patient to the right source of the solution, so he should span more on the x axis and lower on the y axis (something like the Green line). I guess this also applies for Software Consultants, maybe.

But what does all this mean? it means that in order for you, my dear reader, to become a successful professional, you have to figure out how your diagram should look like. How to do that I hear you say?  three things you should be doing constantly to figure this out:

note:don’t try to draw the diagram per se, it’s only a metaphorical way to make the picture clearer in your mind

  1. Decide which field is the one you’d love to make your home? which field you’d want to spend most of your time growing in? When you find that, set it as your base, and then lay related fields in order according to relevance
  2. Think about your role, in general, what is the problem your role usually tries to solve? where in the diagram do the solutions usually lay?
  3. Update the diagram regularly; as time goes by, humanity advancement forces the axis’s to a zoom-like effect: we get deeper knowledge, and we have wider knowledge (as humanity), and so you have to know your capacity, and maintain a slope that covers the proper spans for your role.

And as you may have discovered, the ways used to acquire the knowledge varies depending on the depth or breadth of the knowledge.
Here are some, starting from deep knowledge to wide knowledge:

  1. Teaching
  2. Attending courses, detailed text books, and practice
  3. Videos and community sessions
  4. Articles and white papers
  5. Skimmed reading
  6. Reading titles only, and news on Twitter

Finally, striking a balance between the depth of knowledge and the breadth of knowledge is not an easy task, but let me end with a key tip: I have noticed that most of the successful Software Consultants I have interacted with have a really good breadth of knowledge, and then they bet on their ability to dig deeper when needed.

May your diagram be the highest and widest Smile.

On Building Quality Software

Filed Under (Development, software management) by Emad Alashi on 05-03-2014

Tagged Under :

onion-chopsThe 2nd main cause of buggy software (time pressure is #1), is laziness and boredom.

Every job in this life consists of a “core”, which is the most challenging and most exciting part of the job, and a “chore”, which is the boring and tedious part.
Let’s take a chef as an example; he is an artist whose art is producing quality food, a process that involves mixing precisely-scaled ingredients, perfectly stirred on a period of time, or fried on the grill with an artistic movement…all are actions that the chef consider as crucial part (core) of the process producing the magnificent product of his.
On the other hand, the chef sometimes has to chop onion into xxx-small size of chops, a task that may be really boring to him (I wouldn’t blame him!). Being such a boring task, the chef is tempted to getaway with just xx-small size of chops; after all 95% of the meal preparation is there! So he ships the dish to the customer.
The customer tastes it, he generally likes it, but something is wrong…”ah!”, the customer discovers, “I am chewing pieces of onion!”. He almost rated the restaurant 4.5/5, but just that last bit ruined it!
3/5 is the final rate.

Ok maybe I dwelled a lot in that example, but to some extent this is exactly what is happening with the software developer. The task consists of exciting bits of code (core) that itself is the crucial part of the solution that solves the business problem; challenging, exciting, and fun to do.
On the other hand, the developer has to do some boring and tedious coding along (chore): arranging resources, validation, checking for nulls, breaking code into concise functions, cleaning up removable bits, or disposing resources.
All these tasks are not inherently part of the core solution, but if not done properly… if the developer thought he could just getaway with xx-small chops of onions, … if he does that the software might still generally work, but it will be buggy and less of quality, which will increase the chance of customers’ disappointment, or even abandoning it for good.

Finally, it is pretty safe to say that all the developers whom I thought were the best developers, they all did their chores ALL THE TIME, no excuses; all the tedious work mentioned above is done AND sufficient unit-tests is put to ensure it is done. Their joy of delivering bug-free software is higher than the joy of just solving the mind-stimulating core problem.

Don’t be lazy Winking smile

Don’t Just Fit Into The Gears

Filed Under (software management) by Emad Alashi on 05-02-2014

Tagged Under : , , ,

rusty-gears2Most of jobs in our modern world come with a job definition; a list of tasks that is expected from the candidate to accomplish during his/her occupation of that role. Very convenient approach; setting expectations for both parties.

A convenient approach indeed, but extremely dangerous as well! what is dangerous is NOT the job definition, rather the mentality it instills in the mind of the candidate.
The candidate examines the list of tasks, believes that he can do it, he takes the job, and once he starts in the new role he just fits into the gears of the existing environment/process, regardless of how rusty it is, or how inefficient the mechanics of these gears are! The environment or the process, part of which this role is, could be extremely malformed, inefficient, slow, or of any negative attribute you can stamp on a process that is not 100% fulfilling its goal. Just fitting into this system will make you part of this failure! But for innovators and positive influencers this is absolutely not acceptable.

If you examine any success story that happened within a process or an established environment, you will find that those who caused this success have actually revolted against that process at one point; they didn’t just accomplish “what expected” from them, they didn’t just accept the constraints as proven fact, on the contrary; they took one step back, went out of their specific “role”, analyzed, criticized, and then took a brave action to change. 

Fitting into gears can be expected, to a certain degree, in situations where a job description consists of “rigid tasks”, but it can still happen to roles whose job description consists of “introducing change” (e.g. consultancy). But how can this happen? by:

  1. Being overwhelmed by too many variables: a lot of things might be happening all at once in the environment we want to change, trying to solve all these at once will only result of waste of effort; it’s pretty simple and straightforward formula: x/y=z the bigger y is the less z is. And the solution is simple and straightforward too: focus on the highest priority, and traverse by time!
  2. Despair of change by rigid constraints: decision maker’s mentality, rigid environmental constraints, …etc. All of these can be solved by different ways depending on the nature of the constraint, but  “despair” is the keyword here; once the one reach that stage, he has a serious problem. Despair should not be reached before many trials of corrections acts, and in all different ways, but once it is reached, action should be taken immediately; it’s absolutely not allowed to stay in this situation unless it’s a consciously-made decision. Otherwise, scenarios of escalation, or dropping off, should be valid.
  3. Time lapse: this is the most important point because it is so subtle; what starts as a trial to accommodate to a new environment/process on the promise of change in the “near” future, evolves into an acceptance of the ugly environment/process simply because we “got used to it”.
    The best solution I’ve come across for this problem is talking to influencer people who change things to the better so often that you are constantly reminded that “change” and “making things better” is actually the real task to accomplish.
    If you can’t find such people around you, just print yourself a paper “What can I do to make it better?” and stick this to your monitor!

These three points are not the only ones, many things can also drive to the Fitting-into-gears scenario, though, I find these are the most common.

Of course this doesn’t mean to revolt always and on anything, sometimes something is just right and better left intact.


Don’t just fit into the gears, but step out, analyze, criticize, and change. 

Update Database with Dbup When Deploying With Kudu

Filed Under (Development) by Emad Alashi on 19-01-2014

Tagged Under : , , , , , ,

Update: @DavidEbbo checked the post and thankfully he notified me that we don’t need to use the RESTapi to add an environment variable to Kudu on Azure; we can use the AppSettings in the portal.


Kudu is a deployment engine that enables websites to deploy directly from git repository, it is the one behind git deployments in Azure Web Sites.
Two things I loved about Kudu: you can use it locally in your environments, and it is open source!

There are a lot of video’s and articles that explain how to use Kudu, the source is the Windows Azure Friday, just search for Kudu (using the search box under “Last Friday”, not the one in the header).

In this post I will explain how to do custom deployment with Kudu INCLUDING updating the database with Dbup (a library that tracks your change scripts and deploy them to your database accordingly), both locally and on Azure.
There are some prerequisites for this post, and I am not going to clutter the internet with repeated information; so you will need to know how to

  1. Run Kudu locally
  2. and how to do custom web site deployment.

What are you waiting for, go watch the two videos!

Now that you’re back, let’s see how we can update the database within our deployment.


Deploying Locally

So let’s add a console project “UpgradeDatabase” to the solution and add the Dbup nuget package to it so we can use that console app to manage our database updates.
We need to tell our console app which database we need to apply our change scripts to, we do this by passing the connection string as a parameter to the exe (just like the guide on Dbup main page):

Don’t worry about the parameter for now, we will explain how to supply it later.

Great, now let’s go to the “deploy.cmd” batch file generated in video #2, this file is the batch file that Kudu will use to deploy our website, note here that if this file should be added to your repo so Kudu can retrieve and use to do the deployment, otherwise Kudu will use its default batch file.

Now that we have the script in our hands, we need to edit it so we build the database project and execute the exe file passing the proper connection string so we can upgrade within the deployment.

First, let’s edit “deploy.cmd” so it builds the project “UpgradeDatabse” we created above; we need to do this explicitly because Kudu builds the web project file only, and of course whatever dependencies the project has, but not all projects in your solution. So we add the following line just under the “Deployment” section in the file:

::::::::::::::::::: snippet 1
echo Upgrading the database
%MSBUILD_PATH% UpgradeDatabase\UpgradeDatabase.csproj
IF !ERRORLEVEL! NEQ 0 goto error

Very simple! now that we have built the project we have the executable “UpgradeDatabase” generated, which will be run by our “deploy.cmd” to apply the changes to our database, so let’s add the following lines to the “deploy.cmd”:

:::::::::::::::::: snippet 2
call %DEPLOYMENT_SOURCE%\UpgradeDatabase\bin\debug\UpgradeDatabase.exe %DatabaseToUpgrade%
IF !ERRORLEVEL! NEQ 0 goto error


Couple of paragraphs above we said that we will pass the connection string as a parameter to the console app, and if you inspect snippet 2, you will find that we are actually passing an environment variable as the connection string named “DatabaseToUpgrade”, the question is where do we set this variable? this variable, and in fact all of the environment variables used in “deploy.cmd”, are set by Kudu. Thoughtfully, the team of Kudu have made available for us to edit (except few).
So let’s set this variable.

If you have followed video 1 above, which explains how to run Kudu locally, you have the local Kudu ready in your local machine, through the interface provided we can add the “DatabaseToUpgrade” variable; under the main page of the application you have created on Kudu –> go to the “Configuration” menu item –> Customer Properties –> and add the new variable to the list.

Note: you have to escape the double quotes of your connection string with back lash \





Now that you have added the property with the proper connection string as a value (likely a database on your local machine), we are ready to push deploy, so now we push to the git repo in my local Kudu, you can get the Url from the Kudu interface.


git push http://localhost:4514/bunianlocally.git

Hopefully if everything is set right you will see your change script code executed and your database upgraded depending on the scripts you have put in your Dbup project.

Deploying on Azure

The good news is that we won’t have to do a lot; all what we have to do is to add the variable “DatabaseToUpgrade” to the environment variables on Kudu on Azure, but this time with the value of a connectionstring that refers to our live Database.

The problem is if you go to Azure interface you will find that there is no interface to add such a variable (at least according to my knowledge)! luckily though, and thanks to the Kudu team, we can add this variable through the RESTapi.

So we need to POST the variable “DatabaseToUpgrade” to the resource “settings”, of course the endpoint you will use to access this resource is the Kudu URL on your windows Azure account; you can find this it under your Azure website –> Configure –> and then scroll to Git URL. 
NOTE:The Kudu URL is the same URL but remove the last portion of the URL (i.e websitename.git).

To add the new key you can use any web client tool (curl, fiddler, …etc), so if I omit my personal  authentication header, and using curl, the request should look like this:

curl –data "{’DatabaseToUpgrade’:'liveDbConnectionString’}" http://localhost:4514/settings -H "Content-Type: application/json"

Of course you will have to use the proper authentication to access to this resource, which should be your Azure ftp username and password for this website (at least up until the moment of writing this post). If you need to know how to construct an authentication header by Fiddler maybe this question on SoF might help.

And voila! hopefully you have done it!

Things to keep in mind

  1. The “deploy.cmd” file is in your repo, this means that anyone has access to your repo can have access to the file and change it.
  2. I could have kept the connection string in my app.config file and used a “switch” key rather than putting the connection string itself as a Kudu variable, but this means that I have to keep the real connection string in my code repository, making it visible to all the people who have access to the repo, which is not usually desirable!
  3. Depending the Visual Studio installations you have on your machine, and depending on the way you reference the web targets in your project file .csproj…depending on these two factors, the web targets might not be found during. So keep in mind that you can pass build arguments to MSbuild through Kudu. In my case, I had to pass the Visual Studio version to build upon like the following:




Kudu is awesome Winking smile

Let me know if you have any questions.

Develop without Googling

Filed Under (Misc) by Emad Alashi on 11-01-2014

Google-BrainYesterday I was playing with Kudu, the Azure websites deployment engine, and it was all fun and joy.

While I was happily hitting the key strokes of joy enjoying the new cool stuff I implementing, I got an error, and shamefully the minute I saw the error I copied and pasted it to Google!
For my bad (and later good) luck, after opening two links from the search results I discovered that I am late; I have to hit the road, so I instantly closed my laptop, pushed it in my bag and ran.

In the train I thought I can continue investigating and use my mobile for tethering, the surprise was is that the train became full within minutes, and it was physically impossible to take my phone out of my jeans and juggle with my opened laptop.
”Just great!” the sound in my head whispered… at that very moment I remembered Scott Hanselman’s post “Am I really a developer or just a good googler”, and that was my chance; I kept going on, no Google, no internet, just me, my brain, and the problem.
Being under such constrained situation, you instinctively squeeze your brain and your set of skills to find a solution; it becomes like Limitless the movie, things become slower, you can read better, and you simply “think” deeper.
Before I reached my final stop, I solved the problem! the rush of winning was indescribable.

The lesson learned is not about developing without Googling or having a reference, the lesson learned here is that the internet is merely a tool, it’s NOT your deposit of answers, it is NOT your remote brain; don’t make it think for you; YOU think first, and when you need information beyond your mental capabilities, only then use the internet.

Happy programming.

Complicated Software? Or Solving Everything At Once? Message To Product Owners

Filed Under (Development, software management) by Emad Alashi on 22-11-2013

Tagged Under : , , ,

 iPhone-5-does-everything-comic2 As software developers, we happen to come across many business problems with various complexity levels. Although this complexity depends on the nature of the domain sometimes, what I have noticed that product owners add a lot to this complexity themselves without a need!

For once, software developers are innocent here; the product owner, the entrepreneur, or the man behind the niche, these people have a very big responsibility on defining the complexity of the system; most of the time, the complexity introduced to the software was because they wanted to solve everything with a button, maybe two!

Let’s take an example, let’s imagine that we want to create a vehicle, simple vehicle that transports people around, simple project with simple goal. But the product owner finds that this is too simple, and we will loose potential customers if that was the only functionality in the system!
Ok then, let’s add an arm to it just in case if other customers will need a vehicle to remove obstacles, yeah! that sounds good, now our customer base is larger, and this way the possibility of buying our product is larger.
But man! check how big the customer base is going to be if we just cover customer who need a vehicle that lifts people up to fix high points like street electricity bulbs, let’s add that to the vehicle…and the story goes on!

In theory more features is better, right? the problem is that once we bring something to existence, we bring the burden of managing its effect on the things that existed before, and a long with that the burden of managing the effect of the already existing things on it.
Adding an arm to the vehicle will affect the balance, will increase the danger on the passengers, will increase its weight, and certainly having a big space of passengers will not make the work of arm easier.

And this is exactly what happens with a system that tries to solve too many things, starts introducing too many features that affect each other greatly increasing complexity in magnitudes.

I am not saying that you should make your project dead simple and not grow your product; what I am saying is that your project should solve one problem only, this problem can have many small needs and smaller goals, but adding any of these should be checked according to the following:

  1. can you still use the same words as an answer for the question “what is your product trying to solve” after adding the feature?
  2. Is it an inherent part of the original solution? does it “complete” or does it “add”?
  3. If you have customers already, the majority of them might not be the ultimate reference to your decisions, but if the majority of them agree on a need, then most likely it is part of the problem your product is trying to solve.
  4. The counter point to point #3 above is that, your existing customers might be the pioneers who adopted your product, hence their further needs might be guest solutions to other problems they have that is NOT part of the problem your product is trying to solve; be alert not to be driven away from the original goal.

As for you, my dear Technical Consultant, you have to keep your valuable input to this formula; your responsibility is not only to create what the product owner wants, your responsibility includes warning him, he might not understand the consequences of complicating the solution by trying to solve everything, we have much bigger clarity of the complexity being introduced than what he has; the loops, the decision code structure, the “special” cases, all this you can see very clearly. It is as much of a business problem as it is of a technical one.

P.S. The awesome picture accompanied with this post (slightly edited) is from an inspirational blog post on mylifeinthetechworld , can be found here.

OAuth Authentication in OWIN

Filed Under (Development) by Emad Alashi on 19-11-2013

Tagged Under : , , , , ,

Last week I got the chance to speak on the Victoria .net user group, presenting OAuth authentication (and authentication in general) in the new .net web world of OWIN.
You can find below the link to the source code, the presentation slides, and the video on Youtube.

Source code on GitHub

For some reason the animation doesn’t work on Slideshare, maybe because it was Office 2013

Enjoy :)

Consultants’ Skills: Story Telling

Filed Under (Development, software management) by Emad Alashi on 07-06-2013

Tagged Under : , ,

You have to listen to two words only before Cristian Prieto grasp your attention till the very end of his talk, even if it was about cats! everybody just goes silent, listening carefully, staring and waiting for more!…and the secret behind it, as I see it, is HE IS A PERFECT STORY-TELLER!
Let’s face it, people like stories; we watch movies, we read novels, even news sounds much more interesting when there is a “story” behind it! it is the nature of humans.

As a consultant you want to affect clients and change them to be better: their practices, their way of thinking, their skills… all what you can make better, and the key to all this, my dear reader, is getting their attention! make them aware, make them realize, and what better than a story to do that!

And yes, even the most boring technical idea can be turned into a very interesting story! watching the great story-tellers, I have noticed they have these elements in their talks:

  1. Have a beginning: a “Once upon a time” phrase that is suitable for the idea.
    Examples: “In 2003 at the beginning times of .net, programmers used to…” or, “When the WCF team thought about adding x to the library, there was no…”.
  2. Create a knot: where the peak of the story is formed, either a big problem that will be resolved by the end of your talk,  or a very pleasant atmosphere that is going to be ruined by a sad end of your talk too! (IT industry is full of that, isn’t it ;) )
    Examples: “…developers started using more and more config files, XML was everywhere! misspellings, malformed files, different schema versions…it was crazy!”, or “…the feature really solved a problem, everybody felt good about it because it was just simple!…
  3. Teaser questions, and involve the audience.
    Examples: “…and guess what they suggested to solve this?”, or “What would you if you were in the teamleader’s shoes?
  4. Use profound words with vocal emphasis, but avoid misleading exaggerations.
    Examples: “They wiped EEVVEEEEERYTHING they had on the database
  5. Use hand and body gestures: the more you are involved with the story you are telling, the more effect it is going to have on the audience.
    Example: when you say for example “they wiped the structure of the database” make a gesture with your hand that expresses that. (make sure you don’t offend anyone by any EHM gesture! :P )
  6. Conclude with confidence.
    Examples: “..and THAT my friend what made this feature so unusable in the latest version

On a side note though, this is a talent that you need to practice a lot, and it is NOT easy at all! some people just have it by nature like Cristian, but for the rest of us, we need to practice hard!

ASP.NET Routing & MVC Presentation

Filed Under (Development) by Emad Alashi on 01-12-2012

Tagged Under : , , , ,

Last week I delivered my first talk in Melbourne: “ASP.NET Routing & MVC” with the .net user group VIC.NET.
Even though there was a problem with time control due to reasons out of hand, the audience stayed till the very end of the presentation; good to know that the presentation didn’t suck that much :D .

Here are the slides:

Speed Reading Is Nice…But

Filed Under (Misc) by Emad Alashi on 01-11-2012

Tagged Under :

If you are in the software industry, you HAVE to read, read, and read; and it’s not only the “of course reading is essential”, it’s a matter of life and death…of your career!
And there is tons of material every day: books, blogs, news, articles,….etc., so how to manage? of course is Speed Reading.

Once you master it, yes…you will use it for every reading situation, and at this point, my dear reader, you start doing it wrong!
It is a tool like every tool we have; suitable for some scenarios, and not suitable for others! 
For example, it’s good for the following scenarios:

  1. Unrelated topic: You are a web developer on the .net stack, and your feed reader brings you an article about 3D printing, cool stuff, but is it worth investing your time on? probably not
  2. Filtering: You are looking for something, and you found too many articles in search results, so you filter them out and check which ones are worth thorough reading by speed reading
  3. Extreme situation: someone pointed a gun on your head and ordered you to hack a bank system within 30 seconds and you are allowed to use Google… ok maybe less serious situations but you got the point Smile

And sometimes you just need to read really really slow! every letter, every word, and every statement probably several times, you need to “absorb” the meaning, to think it over, to go deep with the details, to comprehend, cases like:

  1. Applying: if you are going to use what you read to write code! never write a code after speed reading! you have to absolutely understand what your line of code is doing, and whether it is suitable for your case compared to the case of the article.
  2. Judging: you want to buy a product, or want to know how to deal with someone/something/situation, you want to reply/comment on his article…etc. You need to have enough solid information in order to come to a conclusion on how to deal with it, you should NEVER judge or conclude on basis of speed reading.
  3. Dealing with Sales/Marketing/Government/Agreements/Contracts: especially if it was an ad with extremely small text at the bottom that nukes the value of the ad up side down Open-mouthed smile

conclusion: sometimes, you have to read slowly Smile