alt
March 16th, 2010

by Pavel Cheshmedjiev


I tried to make a short review of  some of the best soft skills antipatterns that I have met. The idea is not about mocking or not only about it.  Such epic failures of the art of managing people should be considered very carefully because of their importance in the process of building capable development team or at least finding the right place to work and devote to.

Name: Top Motivator
  • Executor: at least department manager
  • Tone: solid, epic
  • Audience: as much as possible
  • Environment: huge hall, might be canteen if such is not available
  • Expected result: absolute devotion to work and better reporting
  • Key phrase: “I know you are very good professionals, definitely the best in the region/continent/world, but you should keep in mind that – if we lose clients you won’t get your salaries !”
Name: Top Democrat
  • Executor: team or department manager
  • Tоне: polite, serious
  • Audience: only before new team member
  • Environment: office with solid walls
  • Expected result: absolute submission to the manager
  • Key phrase: “Look, my team/department is the best and everybody knows it. We have image, respect, we have everything. But is it nothing like democrasy here. You will keep quiet, you’ll listen to me and we won’t have any problems.”
Name: Top Technical Manager
  • Executor: senior manager of technical department/program
  • Tone: very irritated, pathetic
  • Audience: internal management meeting
  • Environment: meeting room with presentation of slides with coloured boxes
  • Expected result: some tech guy should be ashamed
  • Key phrase: “How dare you lose my time with such technical details ! This is scandalous ! I’m going out !”
Name: Top Professional
  • Executor: senior manager
  • Tone: friendly but hypocritical
  • Audience: face to face meeting
  • Environment: office
  • Expected result: maximized hard skiller’s respect and feeling of  insignificance
  • Key phrase: “I’ve done your job before – I know it very well but now I am a manager and I have no time for your problems.”
Name:  Top Team Leader
  • Executor: team manager
  • Tone: calm, hypocritical
  • Audience: team managers
  • Environment: meeting room
  • Expected result: Team Leader’s reputation should be improved significantly
  • Key phrase: “My team consists of a number of small working bees but they are not capable of achieving anything without me as their only mentor and leader”

Top Supporter, Top Delegator, Top Worker, Top Enthusiast and Top Performance Reviewer will be the subject of one of the next papers, because of their exceptional importance in the corporate life. In fact I think that they are even more important and respectively irritating than the  others because they are directly related to our everyday work.

Thanks for the time.

February 3rd, 2010

by Pavel Cheshmedjiev


In the last 10 years the Java world welcomed many different technologies, frameworks and initiatives. It is getting harder and harder to keep track of all innovations or at least what Ivko does :-) Nevertheless there are technologies that are almost impossible to be missed or neglected. Such technology is the OSGi – Open Services Gateway initiative. For more information visit http://www.osgi.org

While the original focus was on embedded systems OSGi appeared to be too attractive for all in the scope of Java technology. There are a number of papers and much documentation on the OSGi topic so I’ll try to give my point of view and what I think is the real value of OSGi for a typical software developer.

Briefly the OSGi introduces a framework that brings the following main features:

  • Modularity
  • Life cycle management
  • Service orientation
  • Execution environment

So why OSGi ? We have the Object Oriented Java language , we can use design patterns  and different component models.

The first and most important reason for me is that thinking in the context of OSGi makes a developer think in the direction of best design principles such as service reusability, separation of concerns and loose coupling on any application level.  This is very important especially when we design core application layers because usually these layers aim to provide such functionality rather than get use of it. All of these can be achieved with pure language techniques and good practices but not in such lean and standard way. It is also possible that some of the design issues will be left for later refactoring.

Secondly we have all the infrastructure to achieve this – the execution, module, life cycle, service and bundle layers, providing the needed functionality for registering services, life cycle and dependency management etc. We can concentrate on defining the granularity and logic of  the modules of our application , what services it will provide, what are the dependencies and how services interact with each other. Respectively we don’t bother with issues related to the  class loading, application life cycle, service registry etc. Application bundles can be developed and tested in the most agile way – separately, service oriented and with clear dependencies. Once again – we enhance our application design together with all added values from the OSGi specification.

Currently the OSGi Service Platform, Enterprise specification is available at http://www.osgi.org . Now why Enterprise OSGi ? This time it is a bit more confusing – we have the OSGi core, we have all the JEE world – CORBA, EJB, Spring etc and many JEE frameworks are even based on OSGi implementations – from JBoss micro container to Spring DM. Sounds very complicated but the idea is exactly the opposite. We already have the service platform and management.  It is well accepted and adopted. So it is most naturally to think how this platform can be enhanced for the Enterprise world. And what do we need to face the Enterprise world – we need component model, distributed services,  life cycle, session, transaction, persistence management and a set of standard services. So that’s exactly what the OSGi Enterprise specification introduces:

  • Component model
  • Distributed service
  • Web applications and http servlets
  • Event models
  • Management and configuration services
  • Naming and directory services
  • Database access
  • Transaction support
  • Miscellaneous Supporting Services

So on the question why Enterprise OSGi – we have the EJB, CORBA and other component models, JPA specification, DI frameworks and many products that provide similar set of functionalities. So what is new and is it alternative to the JEE world. The new approach that OSGi brings is that it keeps the modular and service oriented nature of the application – we are still thinking in bundles and service, but now a bundle can define a set of components, a component might expose a service and live in distributed environment. We may think of the OSGi enterprise profile to OSGi core as  RMI model to the Java object – it brings many important features, it is transparent, and the main idea is the same. And Enterprise OSGi integrates the JEE concepts very nicely – it does not define alternative of the EJB containers, neither it specifies own persistence APIs – Enterprise OSGi just introduces EJB and JPA service specifications. Existing implementations can be migrated as standard services and keep all the advantages of the specification and their own realization.

So OSGi, Enterprise or both ? Let’s try both with accent on the proven JEE specifications.

Thanks for your time.

February 2nd, 2010

by Pavel Cheshmedjiev


Let’s define reporting skill as a set of similar reporting skills from regular daily reporting, through providing status information, to detailed descriptions of the tasks or just proactive communication to show presence. Reporting skill is one of the most valuable soft skills that a typical software engineer could ever acquire. How important they are will be a topic in some of the next papers, for now we can assume that they are surely in the top 3. We all know what are the claimed corporate benefits, especially in the fashionable agile project management practices. We also know what are the benefits for the engineer – comprehensive daily reporting makes good impression before the management and is one of the main factors for measuring one’s progress. In general we should state clearly – in corporate envioronment proper reporting is much more important for someone’s professional growth than knowing and using latest Java frameworks, design patterns and best coding practices.

It is not that I never tried this skill – I really tried to report and be proactive in the soft skills sense. I tried many times, in many different environments, every time more and more motivated. Unfortunately – without noticeable success. Nevertheless each time satisfied and happy with the progress itself, not the way this progress was acknowledged.

My first reporting failure was in the outsourcing company where I started real software development and continued happily about 7 years. In the very beginnig we reported directly on demand and had some weekly reports where we could explain with a few words what we did. After some years we were acquired by a bigger company, where more dynamic reporting was needed. A few months later while I had many serious development tasks in a very delicate moment I was escalated to my lead engineer that the management had no idea of my progress. They missed mainly proactive mails and stuff like this. In fact I really prefered to concentrate on my work and have it done in the best possible way. This time for the first time I learned one of the most important principles – It doesn’t matter what you do, it does matter what others think you do. In fact I’m very thankfuk to my lead engineer that fully understood my hard skills nature and helped me a lot.

Next reporting failure was a sound one because of the strict discipline and corporate culture in my next company – one of world software leaders. I had to do daily reports, we had different reminders, guides how to do it, automated mails and even human email warnings as last phase. In the beginning I reported kind of regularly, then a bit more rarely and finally I found myself with the human email warning, alerting that is it is the very deadline to prepare my daily reportings for the last two months. What I was doing at that moment – I had digged into some deep source and been doing some irritating reverse engineering activities, due to absolutely undocumented project. I really wanted to skip the reporting part and in the same time to have the last task there – so I put “Code Inspections” for 40 days. I’ll skip the details but it appeared that the normal code inspection time for such period was exactly 4 hours ! Epic fail, resulting with many jokes, respect in the hard skills society and a new signing title “Code Inspector”.

The text is getting bigger, resembling a soft skilled one, so I will only mention about the other big failures and try to summarize briefly. Next time I beated the department “no report” record in one of the telecom leaders in Eastern Europe. My manager entered into the room and tried to make sure that I’ll try to report, at least because of the other colleagues. He also showed respect of my record, because only he had achieved similar results.

Finally I had a recent report summary of 3.5 hours in my current company, where about 500 hours were expected. I was too smart to mention the CTO that we shouldn’t expect that the project burndown chart is absolutely correct because we must assume that not all developers had resolved their numoreous SCRUM tasks. He thought for a while and checked my report summary … a moment of discomfort, disgrace and dis*.

The good thing is that without any exceptions I’ve worked with and reported to very knowledgeable people, hard skillers by nature and never had real problems with my reporting skill and unwillingness for fake proactive behaviour. Nevertheless I always claim that reporting is really needed, but a suitable approach can solve serious issues. What are these issues and what causes them will be one of the next no-soft-skills topics.

Thanks for your time.

Let’s define reporting skill as a set of similar reporting skills from regular daily reporting, through providing status
information, to detailed descriptions of the tasks or just proactive communication to show presence. Reporting skill is
one of the most valuable soft skills that a typical software engineer could ever acquire. How important they are will be a
topic in some of the next papers, for now we can assume that they are surely in the top 3. We all know what are the
claimed corporate benefits, especially in the fashionable agile project management practices. We also know what are the
benefits for the engineer – comprehensive daily reporting makes good impression before the management and is one of the
main factors for measuring one’s progress. In general we should state clearly – in corporate envioronment proper reporting
is much more important for someone’s professional growth than knowing and using latest Java frameworks, design patterns
and best coding practices.
It is not that I never tried this skill – I really tried to report and be proactive in the soft skills sense. I tried many
times, in many different environments, every time more and more motivated. Unfortunately – without noticeable success.
Nevertheless each time satisfied and happy with the progress itself, not the way this progress was acknowledged.
My first reporting failure was in the outsourcing company where I started real software development and continued happily
about 7 years. In the very beginnig we reported directly on demand and had some weekly reports where we could explain with
a few words what we did. After some years we were acquired by a bigger company, where more dynamic reporting was needed. A
few months later while I had many serious development tasks in a very delicate moment I was escalated to my lead engineer
that the management had no idea of my progress. They missed mainly proactive mails and stuff like this. In fact I really
prefered to concentrate on my work and have it done in the best possible way. This time for the first time I learned one
of the most important principles – It doesn’t matter what you do, it does matter what others think you do. In fact I’m
very thankfuk to my lead engineer that fully understood my hard skills nature and helped me a lot.
Next reporting failure was a sound one because of the strict discipline and corporate culture in my next company – one of
world software leaders. I had to do daily reports, we had different reminders, guides how to do it, automated mails and
even human email warnings as last phase. In the beginning I reported kind of regularly, then a bit more rarely and finally
I found myself with the human email warning, alerting that is it is the very deadline to prepare my daily reportings for
the last two months. What I was doing at that moment – I had digged into some deep source and been doing some irritating
reverse engineering activities, due to absolutely undocumented project. I really wanted to skip the reporting part and in
the same time to have the last task there – so I put “Code Inspections” for 40 days. I’ll skip the details but it appeared
that the normal code inspection time for such period was exactly 4 hours ! Epic fail, resulting with many jokes, respect
in the hard skills society and a new signing title “Code Inspector”.
The paper is getting longer, resembling a soft skilled one, so I will only mention about the other big failures and try to
summarize briefly. Next time I beated the department “no report” record in one of the telecom leaders in Eestern Europe.
My manager entered into the room and made sure that I’ll try to report, mainly because of the other colleagues.He also
showed respect of my record, because only he had achieved similar results.
Finally I had a recent report summary of 3.5 hours in my current company, where about 500 hours were expected. I was too
smart to mention the CTO that we shouldn’t expect that the project burndown chart is absolutely correct because we should
assume that not all developers had resolved their numoreous SCRUM tasks. He thought for a while and checked my report
summary … a moment of discomfort and
The good thing is that without any exceptions I’ve worked with and reported to very knowledgeable people, hard skillers by
nature and never had real problems with my reporting skill. Nevertheless I always claim that reporting is really needed,
but a suitable approach can solve serious issues. What are these issues and what causes them will be one of the next
no-soft-skills topics.
Thanks for your time,
Pafka