‘self-education’

The new form of Paranoid Programming

Wednesday, January 27th, 2010



“When everybody actually is out to get you, paranoia is just good thinking.”
Woody Allen

If you go look for definition of Paranoid Programming on the web, you’ll most probably find something like: “paranoid programming is good practice in coding, the sign of professionalism, which implies considering all possible and impossible failure scenarios, and adding appropriate protection from them”. Which means patiently cultivating your fears and nurturing the paranoia, one day you’ll start producing a great output (though you should have enough budget and courage to spend so much time on building such a defensive up-front design). Whilst this old form of “programming paranoia” is peculiar to minority, new form infects almost everyone. And it’s not that positive as predecessor – it slowly drains power and confidence of masses, and pushes them to find the peace and comfort in something more stable, than coding (e.g., management :) ).

So what is the modern programming paranoia all about? It’s about the fear of not being proactive enough in terms of innovative languages/approaches/platforms, and thus getting out of the programming field.  Glancing over dozens of blogposts concerning personal plans for the next year, you’ll find in 99% of them a point about learning new languages (no matter which problems they address – first of all they should be trendy and have a big market share). Majority of those guys are carriers :) OK, I’m not arguing against learning new languages – like in human languages every new one familiarizes you with completely different culture and mentality, introduces you another type of thinking. But is it equal to be able to speak and have what to say?

Surrounded with a great arsenal of powerful toys, majority looks in their production environments for any problem that generally matches the toy’s usable area, rather than finding appropriate tools to solve concrete existing problems. People all around are highly influenced with portfolio-driven self-education (to put as much technologies to the resume as possible), because they afraid to become unemployed. Jumping into new technologies, they stop climbing the learning curve halfway up, not getting to the point and failing to reach mastership in the field.

Being over-proactive in spending time on anything new (which has a vague chance to succeed in future and gain a critical mass of followers) you shouldn’t stay ignorant of fundamental concepts of software development that are true for all languages, methods and times. Considering the real ROI of the time investments you need be very careful and selective, in order to balance your self-improvement process. Java accused of being obsolete can work for many developers for the next several years as a good bridge to new approaches (though they’re brought to market with a huge delay) – just look through the feature-list of the 7th version (also, from my point of view, Java Web Profile is a movement in the right direction – having a well defined stack of technologies will allow developer to save time on picking a suitable set of tools and start designing the system sooner).

In order to protect against paranoia for a long-term, you should be a broad specialist (which is actually highly valued in Scrum) – not just a guy, who can translate business requirements into a programming language, but the versatile developer, who are remarkable for:

- Architectural knowledge. Cutting long story short, whatever trend you follow, you need architecture and design to address complexity. You should learn from success stories, best practices and patterns. Patterns are not getting from anywhere – they’re based on huge empirical experience and sum of observations in technical fields, human society, nature, etc. The other constantly important aspect  is software life-cycle management;

- Managerial knowledge. Even if you’re one of the few, who sticks to coding and don’t want to change the field for administrative work (thanks God, Peter Principle sometimes fails :) ), you may need to classify your managers (like in “Herding cats” by J. Hank Rainwater) and understand what air do they breath to build strong and productive relationships;

- Domain knowledge. Knowing your domain better you’re not only able to provide interpretation of business requirements into code, but also be an originator of innovations;

Tags: , ,
Posted in Software Development | 4 Comments »

3 reasons to work in a big company

Friday, January 15th, 2010





    I’m getting sick of hearing over and over again how cool free-lance developers are. It’s like a cliche or the form of good breeding to talk about their courage and professional skills. I agree, there’s a certain percent of gifted self-employed consultants among them, but nearly the same percent is true with respect to the entire industry. Free-lancers is not an extraordinary caste. Moreover, the most of talented ones are finally being employed by the major players (sometimes, to hold executive positions). It’s inevitable.
     My point is that you have a better chance to become an eminent specialist working in a big company. The reasons follow:

  1. Working for a big company you learn to think big. You can get experience of complex systems design, as big businesses have resources to build the enterprise-scale solutions. The other case is integration of ERP, CRM, ECM, etc.  that normally implies using sophisticated integration patterns and adoption of SOA practices. Being a free-lancer, it is doubtful whether you will participate in 50 man/year development process or complex enterprise infrastructure roll out.
  2. Big companies invest money in innovations and staff education. A lot of businesses invest money in staff education which includes training camps, conferences, coaching. Employees may have some spare time every week for their own activities unrelated to their day jobs (open source projects, reading, blogging). You can certainly spend as much time for self-education as you want being self-employed, but every second you’re not working, you lose money. Secondly, the resources you can utilize. Big companies can spend huge money to buy innovative platforms and software, you can play with.
  3. It’s easier to keep your work/life balance. As a free-lancer your working day starts early in the morning, when you wake up, and ends, when you go to sleep (or more likely, vice verse). Interrupted with hundreds of coffee breaks, football on TV, having a shower and a million other activities you’ll do, if you stay at home. Unless you’re a time-management guru of a great willpower, you’ll fill more comfortable working in the office and having a limited business day. With a fixed number of hours per week you have less chance of burning out and forgetting how does your wife look like. It’s easier to keep up good performance over a long period of time.

     After 4 years of work for a huge enterprise, I’m not going to change the game shortly as I can see benefits clearly, and most probably I will stick to big firms for the next 4 years.

     P.S. First of all, thanks to everyone who’ve found time to give a feedback on my post. I had plenty of interesting conversations last several days. Here’s the short summary:

  1. Majority of freelancers truly think they’re extraordinary (I heard the phrase “freelance is not for everyone” 100+ times yesterday);
  2. Most of the people, who were against my first point, think that patterns and architecture are just for marketing giving no performance or scalability benefits (like, when you use SOA, REST, “cloud”, “grid” and other buzz-words, it’s easier to sell your ideas to CFO). Afterwards they agree that in some cases architecture is finally important, but add that majority of developers doesn’t know or misuse best practices, anyway. It’s not the argument – majority of people are sluggards (including developers, who’ve came into industry for money), who work 9-to-17, then come home, watch MTV, play computer games, etc. The thing I expected is that many of those who think the architecture is all about marketing have came from the PHP world (well-know source of really bad practices);
  3. Many people doesn’t take into account that freelancing implies a lot of business activities (searching for leads, turning them into opportunities, making agreements, etc.) that steal time you can spend nourishing your perfectionism, if you work for a big company;

Tags: , , ,
Posted in Software Development | 24 Comments »

3 practical advices to survive on the maintenance project

Saturday, December 26th, 2009

     Unless you’re not a natural born maintenance engineer and your main target of the life is helping clients of your company (I’m not sarcastic here – I do believe this branch of development is very important and I respect those guys who support for years systems written in COBOL in early ‘80 for their great patience), maintenance is a burden, and your first thought every morning is how to survive this hell. I understand your feelings, as I’ve spend almost 3 years for this nasty activity in the beginning of my career. If you’re a green horn in development, this kind of experience may be useful for you (getting expert in, at least, some technologies; learning business processes of your company; having fun chatting with the customers),  but if you’re dreaming about software architect position and have grown from your pants, maintenance may be really stressful. To keep your brains from being atrophied (and survive on the maintenance project for the better times) you may follow three simple rules that helped me and some of my depressed colleagues forced to maintain legacy code:

-         Don’t spend more then 70% of the day on routine. It’s already a proven fact that statistically you’re not spending more then 6.2 hours per day effectively (so called “in the flow”). If you’re involved in a hardcore maintenance, sometimes it seems like number of bugs in your bug-tracker is infinite, and when you close one, 2 new ones appear there instead. Concentrate on bug-fixing  for 5-6 hours per day (depending on priority of the opened bugs), and spend the rest of time on analytics and self-education. Automate everything (use continuous integration tools, static code analysis checkers, hand-made scripts, etc.), but be ready that your working day will be longer. You may be sure, you boss will commit to this kind of time investments – you mental health and up-to-date knowledge are the most important during the marathon;

-         Read you favorite blogs everyday at least 30 minutes per day to be connected (better 1 hour), listen to technical podcasts in your mp3 player on the way home (work) and spend not less then 1 hour at home for reading books. My personal preference is to read technical/management blogs at work and domain-dedicated books at home (normal velocity is 1 book in two weeks). “Vertical” understanding of the development process is very important. If the pressure at work is too high (say, last week before going live) it’s acceptable to stop reading for some time, but the first free week I prefer to spend 1 day for looking through all the posts I’ve missed. Spend as much time for reading as possible – always have a book with you to read when you travel, wait for a queue in the bank or any other situation when you’re idle;

-         Have as much practical experience during the working hours as possible. Even if you’re tied to any particular platform or technology and it’s not possible to introduce something fresh and trendy in the system you’re maintaining/developing (enterprise giants are often built on their own home-made frameworks, using legacy approaches to architecture, etc.), you still have a wonderful opportunity to practice new technologies during your working hours outside of the product you ship. To train new approaches I’m writing scripts for automation, installation and migration on Groovy and Ruby, internal wiki’s and support portals with OSGi/REST, etc.;

Tags: , , ,
Posted in Software Development | 3 Comments »

Getting started with CRM

Friday, December 18th, 2009
     CRM (customer relationship management) – strategic client-centric direction of the business, on the foreground intended to build reach customer experience of collaboration with the company (in the modern CRM “customer” can be a client, a partner, a supplier or an employee) on the basis of interaction history and analytics produced by Customer Intelligence processes, and on the background, increasing customer lifecycle value, decreasing costs, giving opportunities for up- and cross-selling, etc. (it’s my personal understanding – you can find hundreds of other interpretation on the internet).

     I’ll be honest with you, during my early days at Hyperion I wasn’t too much concerned about the “domain”. Firstly, because of the nature of the system we’ve been developing – half enterprise-scale CMS system, half huge enterprise integration bus for all Hyperion products. It didn’t require too much understanding of the business background, because most of the aspects and pains of that system were purely technical (building a scalable and durable SOA that can integrate a plethora of the other system that were stand-alone before the moment, creating a friendly interface to command all those systems, etc.). The second reason was business analysts that could always clearly and throughoughtly explain what should be done here and there, so that business requirements didn’t change too much during the development.

     Everything sounds good so far, until it comes to adding more real value to the system. I do remember the day, when my manager came to the team, and asked about building a list of things we want to change in the system to make it better and more attractive for the customers. And every single person from the team (me either) added to the list only the points regarding a technical side (cache improvements, change in the persistent layer, etc.). Well, unless the chief financial officer of the company you want to sell your solution to has an IT education, it’s incredibly hard to use “cache improvements” as an argument of the increased ROI :) . This blind approach to development brought us to the following points:

  • We couldn’t introduce an innovation;
  • We couldn’t critically review business requirements and argue about them;
  • Level of commitment was low;

     Nearly at that time I had a chance to read a brilliant inspiring book “Domain Driven Design Quickly” by Eric Evans explaining an importance to understand the background of complex domains deeply, that gave me a clear direction for the next projects.

     So, when I started my path in the NDC of O2’s CRM/CI department I was open-minded and all about not making the same mistakes again – now, on the daily basis I’m gathering information not only about technical aspects of development, but also concerning the business aspect.  Several books and dozens of articles + one designed and implemented system later my recommendations to get started with CRM are following:

  • You must read an amazing book “Business Process Management: Practical Guidelines to Successful Implementations” by John Jeston and Johan Nelis. It’s not the easy stuff to start with (especially, if you’re very new to the business domain), but your own personal ROI after reading this book will be huge. “BPM” written as a guideline/overview to start practicing BPM in the company (so target audience is actually a high level management) and gives a clear understanding of the business process nature of modern enterprises. For me personally almost every single page was a kind of a revelation;
  • The second very important reading is “CRM at the Speed of Light” by Paul Greenberg. This book not only explains in details all the areas of modern CRM (CRM metrics, sales and marketing automation, partners management, etc.), but also gives an overview of the CRM solutions for all sizes of businesses that exist in the market. I personally respect this guy because he’s a great example of a person who has a deep knowledge about the business and IT in order to get as much juice as possible from the both areas.  For instance, in one of his recent posts in the blog he explains benefits of using the lightweight RESTful architecture in enterprises – I can hardly believe, our local business analysts know something about the REST at all (not talking about benefits in compare to WS-*);
  • Finally, you should start following the blog of “CRM Magazine”/ reading “CRM Magazine” itself – I believe, the most influential source about CRM that you could ever find;

     These point are the most crucial to go. At least, you will understand the business requirements clearer (and there will be no unknown buzzwords for you anymore), in practice you’ll be able to argue about them, give your concerns and introduce innovations that have a real business value.

Tags: , , ,
Posted in Software Development | 2 Comments »