Should you move on?

Filed under: , by Tarun Kohli on

In the current economic gloom, it's probably preposterous to even broach the subject of leaving a job  but I was wondering if there was a methodical system to decide if the time had come to switch jobs.

All of us have an inbuilt compass that decides whether the time has come to look for opportunities outside the realm of the current company. It could be for various reasons - lack of role definition, lack of challenging opportunities, unsatisfactory work conditions/compensation or a manager that we just don't get along with etc.

Apart from the "gut system", is there an objective way to decide to look outside? It turns out there is. One can figure out the answer if was one was to earnestly answer the below 12 questions -

  1. Do I know what is expected of me at work?
  2. Do  I have the materials and equipment I need to do my work right?
  3. At work, do I have the opportunity to do what I do best everyday?
  4. In the last seven days, have I received recognition or praise for good work?
  5. Does my supervisor, or someone at work, seem to care about me as a person?
  6. Is there someone at work who encourages my development?
  7. At work, do my opinions seem to count?
  8. Does the mission/purpose of my company make me feel like my work is important?
  9. Are my co-workers committed to doing quality work?
  10. Do I have a best friend at work?
  11. In the last six months, have I talked with someone about my progress?
  12. At work, have I had opportunities to learn and grow?

I wish I had come up with these questions but I just happen to stumble upon them while reading "First, break all the rules" by Marcus Buckingham and Curt Coffman.

The questionnaire is put in such an articulate and simple manner that it helps you bring out the truth out of the closet regarding whether you belong in a specific place, are in a position to contribute and grow professionally. You immediately know the path you have to take if the answers are predominantly towards "Disagree" or "Strongly Disagree". By the way, they suggest that all the questions should be answered on the scale of "Strongly Disagree", "Disagree", "Neutral", "Agree" and "Strongly Agree".

To digress a little, the book was about the fact that individuals leave managers and not organizations. I'm sure you can clearly see that all the areas in the questionnaire can be directly addressed by an individual's manager thus I'm not surprised about their findings. After reading the book, I'm thoroughly convinced that individuals leave because of their managers. I hate to admit but I've had some smart individuals leave when they were reporting to me and now I can clearly see their reasons. I could pass the buck on to the organizational operative context but at the end of day I didn't do enough to realize their potential.

I hope this questionnaire helps everyone who have started to feel iffy about their current position but don't know what should they really do.

Faux Pas

Filed under: by Tarun Kohli on

I didn't realize my blog was completely broken until late evening yesterday. I was using a borrowed blogger template from another site and the lazy me completely forgot to download the images, css and javascript from their site. The ignorant me didn't have a clue that they had bandwidth restrictions for their photobucket account where all the images were hosted.

It was awful to look at the blog and see all the nasty photobucket images asking to upgrade the account as the download bandwidth had been exceeded. Eeeww! I really apologize to all my readers(okay, sorry, I really meant 3 people who visit my blog everyday) who had to put up with this. With my credible intelligence level, I'm glad that on one thought that this was my new experiment in blog aesthetics. Hehee...

Crisis Driven Development

Filed under: by Tarun Kohli on

 

Warning: Satire at work!

crisis I'm one of the blessed souls to have been part of some software teams that leveraged Crisis Driven Development methodology. There has to be certain magnetic force that draws me in to these kind of software engagements. Um...Did I mention I was blessed? Yes, I did.

On second thoughts, it really has to be -

  • the sheer charm of working late hours and weekends so that I get to know the value of family. It truly works on the principle of distance makes heart grow fonder. It tests the strength of all the personal bonds and see whether they are worth keeping.

 

  • the lure of being randomised by always working on some burning issue that needs immediate attention as it affects 0.02% of the users. It truly tests whether everyone in the development team is customer centric and whether they are connected to every single user in the product ecosystem.

 

  • The high of being used just like any other hardware resource till I last my usefulness. It is a test of endurance, how long can one survive a burnout. I would like all the athletes vying for the Olympic gold to be part of such teams. Heck, Roger, if you are listening for ways to beat Nadal, this is it. Vamos, Roger!

 

  • The thought of never getting appreciated for all the hard work that I put in for all the "so-called" crisis. It gets you ready for the real world and makes you thick skinned.

 

  • Having all the crisis attributed to the community of Developers Shavelopers. It doesn't matter whether requirements were changed only 100 times in the process but it should have worked flawlessly once the final requirements were handed over just in time - I meant a day before the final delivery. It teaches the principles of accountability and how to build highly flexible systems that can read the minds of people running the business and calibrate accordingly.

Okay, enough satire but the fact of the matter is that it is extremely disheartening to see projects function like this. What does anyone get by randomising their team all the time? Only a bad product.

I'm not sure if these teams get anything done the right way. The management only stands to lose if the team is always in the crisis mode but they don't see through it. They think the team is fixing issues and rolling out functionality to fix the crisis whereas they are oblivious that it always results in creating more bugs and unmaintainable code base as no one really had the time to think through and do a proper triage.

One needs to learn that building high quality software takes time and the developers need to be given the right tools, the right frame of mind and just enough space to unleash their creativity to create the best of the best.

Have you ever been part of such teams? Would you like to share your experience?

Related Post

Managers are from Mars, Developers are from Venus

Analysis Paralysis

Filed under: , by Tarun Kohli on

 

analysis-paralysis

You know what is worse than taking a bad decision? Yes, you guessed it, not taking one. I've come across some very intelligent individuals who just couldn't make a decision and vacillated between alternatives, even when they did make a decision.

The thing which baffles me the most is that some of them are highly experienced, worldly wise and extremely intelligent individuals. I could spend hours with them talking about anything and everything under the sun and would come out of the discussion learning new things. But, I'm not sure what happens the moment they have to make a decision. They would either tend to consult lot of people before making a decision lest they might hurt someone's feelings/pride or would have their mental tectonic plates gyrate passionately on both the sides.

Something just takes over the cerebral faculties and clouds their judgement. Sometimes, these individuals take so much time that the issue becomes irrelevant. On second thoughts, it might not be such a bad thing at all as the issue does get solved :)  I'm not sure if it is the case of not feeling empowered enough, fear of failure, over cautiousness, or a mere passion for over analysis but they need to tell themselves that they are in a leadership position because someone thought they deserved it(most of the times, they truly are deserving) and they ought to get things going.

The thing that might work in these cases is constant follow up regarding the pending decision after a resolution deadline has been setup. I know it could be hard and there is a chance that you might offend your peer or senior by the regular follow-ups but I've seen it work sometimes.

What are some of the strategies/suggestions you would recommend to tackle this behaviour?

 

Related Post

In State Of Denial

The Future of Management

Filed under: , by Tarun Kohli on

 

Future of Management Have you ever felt that modern management practices in mid to large size organizations sometimes fall short on fostering creativity? Do you feel that your organization is not doing enough to harness the talent of all its employees? Is innovation localized to a select group in your company and you think the management is not doing enough to make innovation systemic? Have you ever had a nagging feeling why HR practices try to bring consistency and homogeneity in a heterogeneous environment?  Do you think the employees are smart enough to manage themselves and organizations don’t need deep rooted hierarchies to watch over them? Do you think your organization is not nimble enough to adapt to the changing business environment?

Well, the book is for you if you answered in affirmative for any of the above. It is a very insightful book, which is divided in four sections - Why Management Innovation Matters, Management Innovation in Action, Imagining the Future of Management and Building the Future of Management.  

The book starts with outlining the reasons why should we adopt new set of management principles and how current management practices are not suitable enough for the new knowledge economy. The second section outlines examples of companies which have adopted the new innovative management styles and are extremely successful - Whole Foods, W.L. Gore and Google. The third section outlines the need to first understand why we believe what we believe and then embrace new principles that foster innovation within an organization. The last section shares certain lessons to become a management innovator.

It's a book which would inspire you to challenge certain norms within your organization. I really enjoyed reading the book.

Social Search: AardVark

Filed under: , by Tarun Kohli on

How do we naturally search for information without using google? No, the answer is not Yahoo. I mean to ask without getting help from a search engine. Unfathomable, isn't it? Well, may be not.

Wouldn't you rather rely on someone from your personal network to seek advice on  great places to see, the best restaurants to have dinner in, the most engaging movie to watch etc. than getting the information through google? Well, I generally get these kinds of information through like minded folks or "so-called" experts in my network and that's exactly the premise of AardVark.

AardVark is a social search engine designed to get your questions answered from your network though instant messaging products. I never thought there could be another way of searching after google but this definitely seems very promising.

Designing for Performance

Filed under: , by Tarun Kohli on

 

bB-2StealthBomber Do you think performance is tuned after the code has been written or is it one of those obvious quality attributes that has to be considered as part of the functional requirements of the system? Considering performance as an afterthought and deciding to tune your software towards the end of the development can only help so much. You really need to consider performance at every stage of software development life cycle. The system's responsiveness needs to be measured and calibrated at every iteration of your product design and development.

One can definitely design systems with that performance as an afterthought notion but I'm not sure whether they would be widely used. Would Google or Amazon have been that popular if they had taken minutes to search for content or books? I bet not. Would Porsche, Ferrari or Stealth Bomber have been possible with the performance-as- afterthought process? I bet not. They were built ground up for performance and speed and they live up to those standards. Why should you believe me? I've driven every single one of them. In my dreams. Every night. Seriously.

So, how does one approach thinking about performance at the design phase? Does one need to employ different design principles for different delivery channels? Though there are specialized patterns which cater to a specific delivery channel like Web, Mobile or desktop based solution but there are some which are overarching and can be applied regardless the delivery channel. IMHO, one needs to consider the following -

  • Caching - Caching of data can dramatically increase the responsiveness of any application though certain considerations need to be made before finalizing the strategy. One could follow W3 of Caching - What, When and Where.
    • What to Cache - It really depends on the application context but anything that would take inordinate amount of time to retrieve and doesn't change that frequently is a good candidate for caching. I also always think about the memory footprint of the cache. I would look at the size of the every object that needs to be cached by enumerating over its properties and computing the actual memory it is going to consume. This helps in the Where part of the puzzle.
    • When to Cache - One really has two options around it - Proactive or Reactive. Proactive Caching is generally employed for datasets(Not the ADO.NET DataSet) that get used in the application in most of the scenarios. It is a technique by which one loads the dataset at the start of the application. Reactive Caching is used when one is not sure when a dataset would get used thus it gets cached it after its first retrieval.
    • Where to Cache - It depends upon how fast the cached dataset needs to be accessed and how big it is? If the cached data doesn't need to be loaded in fractions of milliseconds and is huge then it makes sense to use an Out of Process Cache. But, if the size of the dataset is not that big then one can think about caching the data in the same process. In-process caching gets a little tricky for the web delivery channel when one has a cluster of web servers. As the cache needs to be identical in all the webservers, one has to either develop something in house or use sophisticated products like NCache to replicate the cache state among the clusters.

 

  • Data Structures - Poor selection of data structures can lead to lot of memory wastage and denegenration of performance. Would you really use a LinkedList for storing all your Customers? Would you use an Array for dataset that is always changing? Probably not. I think one needs to decide early the data structures which would get used in the domain model of the product. 

 

  • Algorithms - One not only needs to use the right data structures to store the data but also use the right algorithms to insert/retrieve the data from them. They are tightly coupled and both of them have to be selected in tandem. If you were to sort your dataset, would you use BubbleSort or QuickSort? You wouldn't care if the dataset is too small but using BubbleSort in large datasets could be an extreme wastage of CPU cycles. The selection of the right algorithm plays a huge part in the responsiveness of your application and it makes sense to give a lot of thought to it.

 

  • Asynchronous Behavior - I'm not sure whether asynchronous behavior can  increase the response times of your application but they can tremendously increase the responsivess of your application. In the world of short attention spans and even smaller patience levels, responsiveness means performance. One can use variety of techniques to break the long running transactions and execute them in a step manner while engaging the user. Do you have order processing which runs through a myriad business instructions? Do you have your users see a fascinating marvel called rotating hourglass and twiddle their thumbs after they submit an order? Wouldn't it make sense to break the transaction, put it on a order processing queue and let users know they would be informed when their order is processed? One can easily use some sort of queuing mechanism like MSMQ to decouple the component that submits the order from the service that actually processes the order. In the web scenario, one could use AJAX rather than having the user reload the entire web page again.

 

  • Interface Design - It makes sense to design coarse grained interfaces a.k.a Chunky Interfaces to reduce the chatter among the software layers. It's best to have calls to retrieve and insert data in chunks rathen than invoking multiple method calls to achieve the same logical unit of work. For example, let's say you had an Order class, which had details about the Order, its LineItems and the details about the Customer. Would you have 3 separate calls to create Order, OrderLineItems and Customer or just have one call to create Order, which would execute a transaction to create the Customer if it doesn't exist and then save the Order and its LineItems. It would be prudent to have only one call rather than making 3 independent service calls to achieve this logical unit of work as it reduces the chatter between service layers and help boost performance.

 

  • Data Partitioning - As the slowest moving piece of any application is I/O, it makes sense to give a lot of thought to the database design and how the data would be partitioned in it, if needed.  There are times when certain datasets get used a lot, think of million of hits per day. In those scenarios, it makes sense to partition these datasets with the help of a partition key. The partition key decides how the data would be split physcially. For example, if you are building a social network and you get equal number of english, french and german speaking users then should you divide the users in different databases? It depends upon the context but one should think about the layout of the data persistence. MetaDatabaseIn MS SQL Server 2005, one could even partition a table without having the application ever to know about that the data is distributed in different filegroups. 

 

 

Are there any special design considerations that you know of, which can help boost the performance?