Emad Alashi’s Blog

Today we came across an interesting issue at work: we have two teams A and B who interchange API calls. Team A needed an API from team B to process a business that is owned by team B of course. The signature was like the following:

public OutputEntity MyMethod(List listOfIds);

It appeared afterward that this method was very slow, and the client was already very upset about the low performance, which consequently caused big pressure on the teams by the superiors to enhance the performance.
After investigating the issue, it appeared that the list of ID’s sent as input consists of some ID’s that do not need to be processed, this criteria of “not need to be processed” is a business owned by team B, done by using properties of the entities these ID’s represent. So the  solution to this issue was one of the following:

1. Moving the business out of the API to the client application to do the filtering, since the calling method already has the entities themselves (not so good to move business out of scope!)
2. Let the API do the filtering, but this will worsen the performance because the API will have to retrieve these entities from the database in order to use its’ properties!

So is that a dead end? actually that was stupid! the situation was stressful enough and pressured by our superiors to enhance the performance that we missed a very simple fact: pass the list of entities themselves!

Stressful situations make us stupid, so make as less stress as possible on your team, help them to be smarter.

Last Saturday we had a SharePointSaturday event here in Jordan, in which I had the pleasure of interviewing Joel Oleson and Michael Noel for DotNetArabi.

At the end of Joel’s valuable interview, which can happen only in a life time, I stopped the recording by hitting the “Stop” button, simple. Surprisingly, instead of stopping the recording, Audacity just froze! I could hear myself screaming inside “NOOO!!!”, I guess even Joel heard that! the whole machine stuck that I had to force it to a Hard Shut down.

But knowing Audacity as a great piece of software, which really is, I hoped that I could still retrieve the recording. I rebooted and started Audacity again, and here comes the so refreshing alert at the start:

“Some projects were not saved properly the last time Audacity was run. Fortunately, the following projects can automatically be recovered”

THAT is a successful software! of course I lost portions of the recording still, but I can’t complain; I have most of the interview. So, When you design your software, DO make sure you don’t crash gracefully only, but yet to recover correctly from the crash.

I just finished a session about Communication Skills one-to-one for the MSP program with Microsoft and Jordev. As I promised the audience, here are the slides shared on the very good site SlideShare:

I have been reading this book Growing Software by Louis Testa, and I consider it the book of the year for me.

The book is a about how to create a robust successful software; starting from assembling your engineering team, to having a flourishing company with successful software product/services and happy customers.
If you are a new Development Manager, or already a Dev. manager who is in a small company growing fast, this book is for you.

There are many reasons why I find this book so valuable, here is a list of them:

1. Scope: I haven’t come across any book that covers this scope of what should be done to create successful software; usually books would talk about the SDLC, Development Methodology and Process, engineering techniques…etc, and if you are lucky maybe about some of the best practices around that.
   This book, on the other hand, covers a lot more; it starts from the real beginning of understanding the environment around you, creating an effective engineering team and growing it, defining your product, defining releases, project estimation, project execution, choosing a process, enhancing the process, communicating with other departments, handling customers… and it even covers the future by setting directions, product roadmap and strategy. You can check the main table of contents here
2. Practical: the book is obviously coming from a practical background, it tackles details that won’t be found unless the author really KNOWS what he is talking about, and that he actually lived that experience.
   This is especially obvious when the author talks about the wrong way of doing things. for example, I have always thought adding an unplanned extra feature to a release is a good thing, in fact that was a NO in Growing Software with enough good reasons.
   The real life examples of real instances took place (shown in grey boxes) added a great value; you will always stay skeptical about a theory until you hear someone who had lived it.
   Another part of the practical side is the auxiliary spreadsheets the book provides to tackle certain decision-making situations. No Starch Press provide them for download from their site here.
3. Realistic: The book doesn’t promise you with a sliver bullet, instead it puts the various options on the table and show you why/when you would choose one over the other depending on the situation, injecting this with the experience Mr. Louis Testa has.
   It doesn’t tell you use Agile methodologies, RUP, or Waterfall…it helps you how to choose a process, how to customize it to fit your organization, and how to improve it.
4. For Humans: actually this is one of the best things I liked about the book; I have always believed that we can’t separate business, process, establishments, or evolution without considering the emotions, the culture, and the mentality of the humans involved.
   Reading throughout the book, you can see that this was kept between the eyes all along when it talks about engineers, fellow executives, or customers. Tackling emotions, behavior, expectations and negotiation. Politics was significantly considered in the book when taking decisions or dealing with the different parties
5. Simple: It’s simple; the language is easy to understand, and the structure and sequence of the book is logical. I had no interpretation burden while reading it.

Though, the addressed character in the book is a development manager or a CTO strictly; I’d have really loved if it had shed more light on the Business side of the story, I know it would have widened the scope even more but I believe this is becoming a large need in the Software Industry in general, maybe in another book.
Another thing is that sometimes the book digs little bit too deep in the self-management advices, to extent that intelligent people might want to skip it whole together.

I’d definitely recommend this book for everyone who is interested in Growing his Software house, or being part of it.

Sometimes development tools can be very tempting to a degree that you just want to open the IDE and start hitting those keys. Though it’s not always within the IDE; here is a list of development tools, without specific order, that are just so sweet and pretty crucial to teams opt for best development environment!

1. MSBuild or NAnt
   Build automation tools by which a developers can use XML scripts to automate all the hassle tasks of creating a build: retrieving code from the source control (SC), labeling the source code, building it, zipping it, emailing info, and many other tasks. Both tools are free.
2. CruiseControl or TeamCity
   Continuous Integration servers that utilize the build automation tools to add extra slick functionalities like monitoring the SC, issuing specific commands on specific actions done on the SC. CruiseControl is free while TeamCity is not.
   I once heard a really interesting utilization of such servers; the dev team had red and green bulbs placed in a noticeable area where everybody could see them. On each code check-in action the servers would initiate a build on the server, so if the code builds successfully the green bulb would light up, if the build fails the red bulb lights up instead. nice ha!
3. Tarantino
   I still haven’t got the chance to work on this tool, but it says it does the thing I really wish more companies start to embrace; which is having a separate database instance for each developer instead of shared databases.
   This tool would let the database changes to be incorporated into the SC as easy as code check-in’s (including Schema changes). So in any instance of time, the developer will be able to get latest version of code and sequence of scripts and work on clean ready environment where code and database schema is 100% compatible.
4. RedGate Sql Compare
   It enables you to compare two database instances and to elicit a change script from this comparison. One of the many features, by which it supersedes its free counter part SQLCompare, is that it can be initiated from Command Prompt. costs at least $390.
5. TortoiseSVN
   SVN(SubVersion) is an open source SC. TortiseSVN is an SVN client that integrates with the Windows shell. Lovely, robust and free.
6. AnkhSVN
   it’s an SVN client too, but integrates with Visual Studio so you don’t have to leave the IDE to manage versions, indispensable. It’s free.
7. TFS sidekicks
   if you have ever dealt with TFS administration, you’d know how cumbersome it is. TFS SideKicks is the solutions, period!
8. NUnit or xUnit
   For the ones who haven’t heard of Unit Testing tools (I hope you are few!), you will be able to write code to test your code; and with nice GUI which tells which part of your code fails. Both are free.
9. IE8 Developers tools, Firebug for Firefox
   These are awesome client side environment tools; Debug Javascript, Profile Javascript, and manipulate CSS on the fly. web devs can’t live without it really. both are free.
10. Fiddler
    inspects http requests made from your browser, with details to the smallest bit came into your machine through http. It’s free
11. WinMerge
    The best diff tool out there, I wish I could replace it with every IDE Source Control plugins, it compares folders too. It’s free.
12. BugTracker.Net
    If you have a small team of devs who work on low cost and tight budget project where you can’t use Jira? this is THE bug tracker software I choose. I love their new feature integrating with SVN. And it’s free.
13. DPack
    Code navigation tool; light, handy, free.
14. CodeRush or Resharper
    code assistant and enhancement tools, makes you create, change, refactor code in couple of key strokes. They are both not free except CodeRush has an Xpress version

I am sure there are others slipped out of my mind, but I believe those are fun enough to play around with. enjoy

It’s a waste of time trying to explain how important communication is in life, whether it is at work or personal life. So I will start immediately in group of points I find it to be basics when it comes to successful communication in general, and verbal communication in specific.

Here is the list of actions you need to take in order to explain your thoughts as clear as and descriptive as possible. I tried to put them in their proper order considering the communication process, though they can overlap:

1. At the beginning of the conversation, make sure that the goal of the conversation is clear
   e.g. “the goal of this discussion is to discuss the problem x, and to find a proper solution for it”
2. Put the listener in the context instantly
   e.g. “Remember the remark our client made on the page where we list his system users?”
3. Unify the terms used in the discussion; giving special words to commonly used meanings and expressions
   e.g.  “users who are still work for the company but for some reason they are not available we will call them Deactivated Users, users who don’t work for the company anymore will be called Deleted Users”
4. Start from common ground of information
   e.g. “As you already know, this list is too long and a scrollbar shows, and you know too that the architecture team provided us with a tool for paging, now the problem is…”
5. Sequence of thoughts is highly important; you should start from the most intrinsic and basic thought and build on it to conclude to the next, each thought should be a building block for the next
   “we are advised to use tool x for this problem, tool x uses technology y, technology y requires us to buy that license, and we cannot afford it right now, so what we can do is…”
6. Aside from the terms in point 3, use language words that are understandable by the listener; don’t use a unique dialect for example. For this point I will give a negative example:
   e.g. An aussie would say “Don’t get your knickers in a knot”, when he really means “Don’t upset yourself”
7. Don’t deviate from the subject or add information that is useless to the subject; the more you talk about irrelevant subjects, the closer to failure the communication would be. This point too should be explained with bad example:
   e.g. “Yes, this can be fixed but it only requires a small action from Ahmad, who happens to be working with the architecture team right now, on a new feature in the framework that might add a new challenge to our application because we will have to change the….”! 
8. Don’t try to over explain the idea more than it needs; use short expressive words.
   e.g. “I get server error exception” rather than “I get error showing tags and line of code in the vb file where the error happened because it is an error from the server as you know”!
9. Talk in digestible speed, a speed that suits the listener not you; reminding to point 5, thoughts are delivered in sequence, make sure the listener digested the current before you move to the next
10. Ask questions that help the listener to understand, when you already know the answer, but you want to reach certain point with the question where the listener will have to think clearly about it
    “When request a page, what happens on the server?”
11. Confirm that the listener is following right by asking regularly
    “are you following?”
12. if the listener failed to understand at some point do the following:
    1. ask what part exactly he didn’t understand in order to take the proper action
    2. DON’T REPEATE THE SAME SENTENCE! rephrase the sentence in a more understandable way (needs a lot of training, I agree)
    3. Step one level back in your sequence of thoughts, probably the listener didn’t understand because of failure in explaining the previous though

By this I end the basics of successful communication, it’s not easy to follow these steps I am sure, it needs a lot of practice, especially when it comes to choosing words and preparing the sequence of thoughts. But if you practice enough and  you master it, your life will be much easier

I hope you benefit and have a nice discussions around

When I started this blog my goal was to make it a technical one, in which most posts would have code, samples, screen shots, architecture…etc. This was the primary goal, though it is totally fine with me to talk about software life in general.

The issue is that I get the ideas of my posts from my real daily life, which is mostly code challenges at work. I do write code in my leisure time, but for sure it is not as thorough as the thing at work.
And since I haven’t posted any technical stuff lately…the simple conclusion is I DON’T SEE CODE ANYMORE!

A Technical Team Leader in the place I work at right now has a different meaning from what I knew before; the first word in the title is “Technical” so I expect to deal a lot with code: planning it, reviewing it, discuss it with team members…etc.
But in the environment I work at, there is more pressure toward management and coordination; I find my self during the day doing stuff like updating the Microsoft Project plan, smoke testing, running between other teams we depend on to get their deliverables; checking with the User Experience team if they have the designs ready, checking with the Architecture team if they will pass by to set the folders structure for us…etc. All this leaves me no time to see code.

Is this right? Should a Technical Team Leader do these stuff? If not, who should? Is it a Project Coordinator? what is exactly the job description for a Technical Team Leader?
Questions like these should be discussed with the Development Process people, but till then I will have to say: “that’s not right”.
How about you? what do you think?

When we started gathering requirements from the charity organizations for Bunian, it appeared that there are other kinds of people who benefit from the charity organization; there are “needy families” whose father is still alive but can’t sustain their families, and “students” who can’t afford their study. 

So Bunian needs to support all these Beneficiaries in smart way; we solved the problem by creating the IBeneficiary interface. But the problem is that in order to get out with the best solution ever (damn perfectionism!), we kept coming up with different solutions, and overriding them with other solutions every once in a while, and this kept going like forever!

Though we agreed from the beginning that we shall keep it as simple as possible and then add up to it as we get out with the first phase, yet it kept sliding “ok only we have to do this, oh and that too”. Until one day I thought I came up with the silver bullet everyone talks about , and sent an email to the group about the changes I wanted to make, when a colleague caught me online and showed her objection about the new solutions, and proposed another. Only then I woke up!! “OMG…WE ARE STILL HERE!!”
Instantly, I remembered my oldest brothers comment  (Mohammad, very wise brother) about Bunian “It’s great that you want to build the greatest architecture ever, but remember that Orphans are waiting!!”

So LET’S JUST GET ON WITH IT!! ship it!! do it!! let version one come out, let “customers” benefit from it, then you take your time doing your silver bullet. So this is one of the challenges facing the Project Managers, something we developers rarely think about ; today…I learned my lesson!

Lately we have decided in Bunian to move on to NHibernate 2.0, and the contributor assigned to the move started out, only to send an email one day after: “THERE IS NO DOCUMENTATION!’.
We had errors as a result to the move which couldn’t be fixed without a documentation explaining why this happened.

After searching for a while, we found two resources of the new documentation:

• a wiki help that is hosted on Google Knol:
  http://knol.google.com/k/fabio-maulo/-/1nr4enxv3dpeq/21#
  Not really appealing to be used extensively; no smooth flow between chapters, frames dazzle the eyes, no table of contents, but surely a great step forward for a documentation that is maintained by the community
• and online ordinary documentation as HTML:
  http://www.nhforge.org/doc/nh/en/index.html
  which is my preferred way for documentation (or at least until the wiki proves its usability)

Neither links were included anywhere in the NHibernate zipped file.

I didn’t realize how important a documentation is until it stopped us from moving on in our project; Only after we made sure that the documentation is available we decided to move on to version 2.0. The lesson to be learned is that if you are an enthusiast developer and want to add another piece of code to the world, keep in mind that your project is not only code; it is people, resources, community, ease of use, documentation, and any other simple thing that people need while you think it’s not important.

Of course I couldn’t find developers or contributors to open source projects greater than the NHibernate team, having such a project in the first place is awesome, and I thank each and everyone of them. I hope one day I can really contribute back to NHibernate. Thanks again guys.

If you don’t know it:

Once upon a time there was a group of little frogs, who decided to go through a competition to climb a tower. The tower was high and difficult, and no one of the spectator frogs believed that any of the tiny frogs can make it to the top.

Little frogs started climbing, while spectators yelling:
- "oh my, it’s too high…I don’t think they can make it!"
- "they are too young, how possibly can they reach the top?! that’s insane"
.
.
Shouting and yelling continued, while the little frogs surrendering one by one, except for this one little frog who kept going and going, climbing up further and further more. Surprising everyone, that frog made it to the top and he won the race! well…the only reason for his success that…HE WAS DEAF, he simple couldn’t hear the negative shouting of the spectators!

1) The effort a man produces trying to succeed is proportional to the amount of expectation to succeed
2) and the more effort he produces, the more it is possible he will succeed.

So if one member of a team starts putting the team down, the teams effort is absolutely going down, even if they can make it, they won’t. no passion, no effort, no success.

The only thing you will get from being around negative people is being pulled down with them; they will keep discouraging you, to give up, to stop you from reaching your goal! with all sort of discouraging words:
- "the way we work is wrong, this is stupid! this is never gonna work"
-  "I knew it! I knew it!"
-  "the client is going to reject it, I am telling you! he is!" *with yellow smile*
Enlarging the disadvantages of the surroundings, and forgetting about the advantages, putting the passion off.

Yes, there are annoyances, but come on, NOTHING IS PERFECT! any sane human would obviously tell you that "not getting all" doesn’t mean "giving up on all"; if you do that, while there is nothing perfect, obviously, you will end up losing all!

Believe in yourself, try to improve, never surrender. And while doing all that…just enjoy what you have.