Reuse should be side effect and not the goal

Last night,I had a talk with one of my friend who is also a developer at some other company,In his project,client is always looking for cutting the corners by which he could save on cost of development.

As a clever IT manager,For faster development,client’s IT manager is insisting on a design which has reusable components identified and well laid out,while my friend is collecting requirements and doing the requirement analysis. But to my surprise,my friend is also feel good about this notion.I think I am bit behaving like a pessimist here but I am somehow feeling uncomfortable because of this thought…since here they are treating the goal of system designing or architecting as reuse while ignoring the sole goal of architecture is to better serve business…to find the solution for business…

In my opinion, reuse should be side effect of your design and not the goal of your design.

Certainly reuse is a good thing to have inside your system but it should emerge rather than we impose reuse as goal on our design.It suppresses the creativity of fitting and integrating the different aspects of the system as well as it dangerously introduces the dreadful impact of looking the entire world into black and white rather enjoying the diversity and cleverly utilizing diversity as a strength of system.

The trap lies in perspective of architect or people who are designing the system since “emerged reuse” can co-op with inherent business changes that are going to come in lifetime of system while in case of “artificial or induced reuse” system can not withstand with the upcoming changes of business.This happens and I had observed it since "intended reuse" imposes "reuse" as a goal rather than just a strategy inside the system.
So the components are built with keeping today’s constraints in mind.While architect or even end users of the systems are not sure that whether today’s constraints will be there in future or will be removed.

Just on a curious note,Have you anytime observed reuse as a goal?


Share this post :

Why Your Agile Project Can Not Be A Success

  1. You think agile is iterative waterfall.
  2. Somebody from your top management told you to use “agile” methodology on your project.
  3. You think Product Backlog = project plan,iteration = milestone , scrum-master = project manager,sprint retrospective = project status meeting and agile discipline = micromanagement.
  4. The sales team decreased your estimates because they believe you can work faster.
  5. You use same estimation techniques for waterfall and agile project.
  6. Project estimates magically match the budget.
  7. You have project manager on the project who is in charge of everything.
  8. Every Friday, your project team work on data collection and prepare metrics for your project managers.
  9. Your team do not have scrum master.
  10. Scrum Master do not participate in coding and testing.
  11. Your Scrum Master do not understand the acronyms DRY, YAGNI, or KISS.
  12. You had all the requirements predefined in specification document and you think project will be get executed according to specification.
  13. You think design activities are ,a time to fully and accurately define designs and models in great detail and programming as a simple translation of these to code.
  14. You try to plan a project in great detail from start to finish.You try to speculatively predict all the iterations and what should happen in each one.
  15. Your managers swear by Microsoft project.
  16. Your managers haven’t read “Peopleware” and “Mythical man Month”.
  17. You do not know anything about your team’s “velocity”.
  18. Your project teams don’t have burn down charts.
  19. You define all the architecture upfront at the start of the project.
  20. You have only one iteration.
  21. You think refactoring as a rework.
  22. The last book read by your senior developer is “Mastering VB 6.0”.
  23. Your software architect work in silos.
  24. There is no or minimal feedback and adaptation;users are not continuously engaged in evaluation and feedback.
  25. You think  “Test engineers”  cannot be introduced from day one of project since no code is developed.
  26. Everyday your developers work until Midnight everyday.
  27. You think software quality means creating some CMM compliance documents.
  28. Your QA team does not know how to code.
  29. Your test engineers could not code.
  30. You have specialized roles on your project teams like developers,test engineers,project managers.
  31. Your developers do not practice J/N Unit.
  32. You see deviations from requirements or design during later steps ,as failure or concerns in not having sufficiently skillful or through.Next time,you try harder to get it right.

If despite all these odds, if somebody is claiming that their projects are successful then I have no doubt that there are some software heroes working in their organization;who might be thinking of leaving that organization ;)

Balsamiq Mockups Review

Nowadays I am doing requirement gathering and analysis for a good project here in Gibraltar.So you can imagine lot of user interactions ,taking interviews of end-users , sometimes shadowing them to their specific work function and lot of questioning etc are going on…at least project started off good and we are heading in correct direction.

For successful execution of project,the team which is going to implement or code,should get understanding of the ideas and concepts and functionality and thus the need of good mock up tool arise. These tools plays a vital role of explaining the ideas and bringing the life to boring documentation. It is truly said that “1 picture is equivalent to 1000 words!”.

In my previous projects,I had mostly used visio and its sort of standard at my workplace for mockups.Though recently I had also tried out serena prototype composer for one project.These tools have their advantages and disadvantages.

Visio is the huge software.It is not meant just for prototyping or diagramming.However,it comes at a price and it requires a lot of time to starting off and be expert with it.You can find massive features are poured on as just any other Microsoft stable software.After using visio ,I came to a conclusion that visio is good tool ,but still not a very handy tool for creating mockups quickly.

I explored a bit more on internet and found Serena Prototype composer.Serena prototype composer scores over visio ,when you want a clickable prototype.But then serena prototype composer needs to be installed where you want to run your prototype and seems to be pretty rigid kind of a tool.I didn’t like it much though it has unique advantage of creating clickable prototype.

Then again in search of perfect mockup tool,I downloaded and tried many. One day(actually night),when on the verge of just concluding that there is not so much great tool other than visio,I found the gold “Balsamiq Mockups”!!!

As a practice,Without much hopes,I downloaded and installed it.As a authentic software engineer,I never use manuals or help to use software [In fact,I had reached to conclusion that if you need help or manual for running a software,there is a problem with usability of that software]. Firing up balsamiq tools,I was just kind of landed in my dreams!! Since,it is just made for making mockups!!! Very no not friendly,I will say inviting user interface.there are all UI elements at the tops with really big and wide tool strip which shows of drag and drop user elements some common like buttons,text,all types of containers(i.e. group box,tabs etc) and some uncommon like accordion,cover flow,video player,street maps etc.The most surprising is I found sticky[comments as they call it ] and charts and graphs as well.Wow! pretty genius work.Since,many business software always need this and very few people do have mockups for this stuff.


You can create a new mockup and start building your mockup by dragging and dropping these elements.When you drag and drop the vertical and horizontal guard lines appear to assist you for placing the elements,taking care of alignments which is again cool feature.

You can set properties of individual element by selecting the element and then property bar appears out of nowhere.You can drag it anywhere so that it will not disturb you or obscure the view of element that you are working with.Also The properties are fantastic set,Just as what needed no extras .These things truly live “YAGNI(You aren’t gonna Need It!!) agile principal.

On top of this,the mock up you created can be saved or imported as XML file or can be exported as PNG files.

Balsamiq Mockups team has really come up with really genius product !!

However,there is a saying that greedy man and end-user can never be satisfied  :)

I must also point out some things that they can improve into their next version.

After using it for two or more weeks ,I realized that grouping and un-grouping of containers and their child elements are somewhat confusing to me.Since,The controls that we drag goes back side of group box and another thing I wanted is the ability selection of many controls like visio gives. As of now,to move entire thing,we have to group them.There must be the selection ability for controls that are not grouped.

The community of Balsamiq Mockups is also good.And they had come up with several templates that you can find at .

All in all,It is insanely great tool built by genius people out their at Balsamiq.I think I can saved at least 40% of time required to create mockups with Basamiq compared to Visio.I will certainly recommend that try your hands on Balsamiq and you will be happy making your mockups ever after.


Share this post :

Types Of Software Companies

A 640 BC one-third stater coin from Lydia. 

Technology i.e. science and Management are two pillars of IT shops.The main theme behind separating these two terms is because of the ways these terms shape the culture of company.

The visible attributes of the the companies which value Technology as equal as Business are their software engineers/techies are to be believed as most precious entity in the organization.These companies are trendsetter in their own chosen field of work.The designation does not matter for raising your voice in arguments and expressing contradicting views to that of your colleagues[read your bosses if you are in management stuffed company].You can be your very own in such a environment.You can practice your craziness and spit out any damn idea or coin a new funky term,the only thing that matters is how good you are in your work.
These companies are often run by media shy and only get recognized by their products or when they broke out their new innovations.

On the other hand,there are companies that value Business more than technology.In such setups,software engineers/techies are treated like commodities.These companies are mostly flourished and dominated by some kind of management degree holders.These folks believes on laying down strict sense of organizational structure.These companies are more often profit tearing companies.The way they operate is more frequently like any other manufacturing unit.You can here lot of meeting agendas and close door discussions.Employees are more often pointed to their policies and often seen having water cooler gossiping etc.These have very good frontal face as they had good PR,Marketing departments those pays heed towards media.

Think for a while and comment about Where are you working now?

Share this post :

Cost Of Not Upgrading Developer’s Computer

Computers and Servers repairing snapshotMany times, there is situation where people in SMB and startup businesses do not upgrade their computers and perhaps their software tools too. Most of these businesses think that it is pretty ‘OK’ to run things as it is ,for years since either they are running the same things.And upgrading systems would add up to their cost.But they eventually forget the cost of loss of productivity of developers. This added cost would certainly pain for customers as well as it can harm your business severely.

Let me give you an example,If there is some code base of your product, which takes 3 minutes to build and compile and run on normal [read upgraded or having latest hardware and software], and you had a machine with your developer which is taking 7 minutes and project would gone up to 24weeks and developer had generally compiled solution even only 50 times per week then you are losing the productive time of 2 Person-Days. Assume, you had 8 working Hours per day.

Time lost in each Build/compilation = 7-3=4 minutes.

24 cal. Weeks = 24 X 50 X (Time lost in each code compilation) = 120 days.

24 cal. Weeks = 24 X 50 X (4) = 4800 Min/60 =80 Person-Hours= 10 Person Days].

So for 6 Calendar Months of work the organization is losing 10 Person days per developer.

Doesn’t that is good eye opener for managers? I think that is quite a lot valuable time and that it is wasted just because you had not upgraded your hardware or software system.

Sometimes, many of us forget that we are using computers just because those damn good and fast machines can do tasks faster than human can think of.

Share this post :

Becoming A Star Engineer-Part III

This is final part of article of Becoming A Star Engineer.You can go through Part-I and Part-II.

Becoming a star

We conducted a long-term study evaluating how productive engineers were before and after they had learned star work strategies by going through our productivity improvement program. Currently called Breakthrough, this program has been taught for the past seven years to over 1000 people in many companies not only in the United States but in Europe as well. It is licensed to professional training companies and is being used in universities both in the classroom and for staff development

As a basis for our evaluation, we met with managers, star performers, and average workers, asking them to list the factors indicative of increased productivity in a person working in their departments. Several iterations ensured that people who rated highly on these factors were indeed highly productive.

Then we asked direct managers to rate 300 participants and 300 nonparticipants on this list of productivity factors, once before the training sessions began and a second time eight months after finishing the program.

On the basis of these managerial evaluations, program participants were found to have increased their rate of productivity improvement significantly. The engineers who went through the program solved problems faster, produced higher-quality work, and consistently impressed their customers.

The star strategies program is not a remedial course for poor performers. About 30 percent of the participants taking part in our productivity improvement programs already were wearing the star producer label. Their productivity gains have been similarly impressive.

The most dramatic changes were in the ranks of women and minorities, according to their bosses’ pre- and post-evaluations. Their productivity improvement rates shot up 400 percent on average.

The success of these groups underscores a key finding in our work. Becoming highly productive does not require magic. When engineers produce at undistinguished levels, it is seldom because they are less capable–it is because they never learned the work strategies that lead to high productivity. Once these engineers are given access to the star strategies, their productivity takes off.

Author :Robert E. Kelley

Share this post