Under the radar programming

Public Domain, https://commons.wikimedia.org/w/index.php?curid=1183115
Some cool looking spitfires. Not quite under the radar but imagine they were...

Under the radar programming: blending some good quality software development with some "other stuff". The air corridor where all the great software is conceived in large organisations.

Large organisations are usually so swamped with mediocrity that nobody at any management level believes that anything decent can come out of any development team. It is usually futile to ask for air cover while programming/changing a major part of a system.

So take a business deliverable, enrich it with good quality software development (under the radar).

Three strikes and you automate

"Tuerkischer schachspieler windisch4" by Karl Gottlieb von Windisch - Copper engraving from the book: Karl Gottlieb von Windisch, Briefe über den Schachspieler des Hrn. von Kempelen, nebst drei Kupferstichen die diese berühmte Maschine vorstellen. 1783. Original Uploader was Schaelss (talk) at 11:12, 7. Apr 2004.. Licensed under Public Domain via Commons.

How many times did you hear this;

Mates 1: Hey setting up that uat environment was a pain ah? I had to swipe fairy dust from the unicorn’s horn and mix it with dragon tears...
Mates 2: Nice one mates, but did you script that up so that I don’t have go after that dragon next time? 

Everyone likes a good automation no? You click that magic button or run that nice script and things happen. Nice.

However, how do you know that you will ever need to do that again? Or, who will look after that script that you knocked together this afternoon? Automation is good but has a price tag (maintenance) like other good things in life.

So when to automate?

How about the same rule as re-factoring? Three strikes and you automate. If you need to set it up once, do it. Twice, do it again whinging and cursing. Third time is the point where you need to think about automating. Not before.

Less is not more for once.

(later edit) well, this has been done before in c2 wiki. #LetMeGoogleThatForYou!

Enterprise software lifecycle

I have seen this cycle enough times to grant a blog entry.

The enterprise application software cycle can be summarised as:-

• good abstraction
• lack of understanding and respect
• force programming

This is how it goes;

A new team arrives to the scene. Takes a look at the application and decides that it is totally not good (lack of understanding and respect).

They start force programming it for a while, making the issue even worst.

They may understanding what is going on in about a year or so, re-do some of the work and may arrive to good abstraction stage.

The team mostly leaves, a new team arrives and we are back to the future.

What can be done about it? Well, it is hard to skip the lack of understanding but we can skip the lack of respect and force programming bit.

The trick is to live with the system a bit and investing enough time to understand, lay on you hammock a bit, do a bit of in the shower programming.

Don't rush to conclusions.

Traits of a good team leader

Having worked in quite a few teams and led some, here is my incomplete best of list;

Manage the team as well as the task in hand; Obvious but most overlooked aspect of team leading. Teams change and evolve. Work changes, people change, their opinions change. Leading the team means actively managing the team dynamics as well as the task in hand. Talk to people move them around, get involved.

Lead by example; Team leader should simply be a well respected programmer. It is not easy to get the best programmer in the bunch to lead the team. Some are simply not interested but team leading is not a job just for the asking or a matter of seniority.

Keep it real; Programmers are usually well educated and very clever. They have sophisticated bs detectors. Peep talks don't work. Timelines should be realistic, targets should be achievable. A solid plan is easier to deal with mentally. Lack of a plausible action plan leads to low mojo.

Be approachable; Team leaders should spend a good deal of their time to help/lead team members. When someone asks for help, be it code review or a bit of pair programming, it should be the first priority.

Delegate appropriately; Distribution of tasks is an important part of team leading. Agile environments make it a bit easier with user stories and tasks but every team member should mostly know what she is doing and should feel appropriately responsible for the outcome.

Don't just pass on; Filtering is a primary management function and works top down as well as bottom up. So don't pass on all the management pressure to the team members.

I need that estimate and I need it now!

Throughout the years, I have been involved in more than my fair share of planning and estimation of software projects. To put it more precisely, planning to be able to estimate.

This is not about scrum planning or likes, this is more about estimating in grand, like 'plan and estimate that companywide pricing infrastructure'.

Here is a little quiz for you.

What is the purpose of estimation in software context?

a. big stick to flock development teams when the estimate over runs
b. box ticking exercise to create illusion of success
c. job creation schema for middle management
d. a tool to help make decisions.

If the answer is not loitering around d, estimation process starts to become actively damaging.

For a start, estimation requires some (or a lot) up front design, which is bad if not wrong for most of the time, which gets documented, sent to places that are not easy to retract.
Trying to come with estimations on imaginary solutions, writing all that is a real soul crunch, etc.

I think you should always come back to the naive question, why?
Why are we trying to estimate? And loop back to why until you arrive to a "real" decision point, by passing intermediaries like, 'I need those tasks' or 'we need a time line' or 'the management asks for this really'.

Is there a real alternative? Is it possible not to implement this? Are there alternative solutions? Or can you go ahead and buy a similar thing?

People are often a better bet than processes. Everyone wants to do a good job and take pride in it. Put together a good team, get them to work close without distractions and let them get on with it!

Adventures of a programmer turned food critic

We were at one my favorite restaurants barrafina (best tapas bar ever anywhere, including Barcelona) the other day. Between gobbling up the octopus and tucking into the tortilla, I have been watching the lovely master chef running her kitchen under military discipline right in front of us. The food preparation process must be similar in all fine restaurants but I never paid attention as it is usually behind closed doors. But being a tapas bar, it was happening right in front of us this time, very inspiring.

The preparation of various types of food is delegated to less senior chefs, where the more senior (guessing by the looks) ones were tasked with harder jobs. There is a certain area of responsibility for everyone. When an order arrives, it is put to a place where everyone can see, everyone picks up his part, prepares it and the prepared food ingredients are brought in front of the master chef. They are ingredients tho not the finished dish. If it is pork belly with a certain type of sauce, the sauce and the meat arrive separately. The master chef does the final mixing, seasoning and tasting? and prepares the final dish to be presented to the customer. Fantastic.

The very last bit of the process is of crucial importance. By putting the final touches, chef makes sure the the final product is always of great quality.

Here is a task for team leads in software teams. The team lead is responsible for what comes of the team, so why not review all the code, line by line with the programmer, before production? I realize it may be a little frustrating, given the quality of code I have seen through out the years, but a crucial step for producing systems of similar quality to the legendary tapas in barrafina.

Trigger happy programming

You come across an issue like say, the code is dog slow. What is the course of action? For the stuff I do for fun, I rewrite the whole thing. But being a responsible citizen, I don't do such things at work. Here is what I do; (for a more philosophical discussion of problem solving refer to 'zen and the art of motorcycle maintenance')

I have been programming for a while, I am entitled to have a hunch. So I do a bit of 'shotgun debugging' which consists of randomly fixing pieces of code which look like probable causes, hoping that the problem goes away. Sometimes it does go away, we go to the pub.

There should be a limit tho where you start to experiment in a more controlled way. Measure, change one bit, measure again. Change only one bit at a time. The transition between two modes of action determines a programmer's 'trigger happiness factor'.

There are two considerations, usually highly correlated, to make the call for the mode switch; the amount of programming time required and the depth of code that will be replaced.

I have seen people replace whole sub systems on a hunch, spending months. Some are good programmers and can get away with it, I am usually cautious.

Anyway, there is no conclusion here, all you have to do is to keep it real.

Rabbit in the headlights

We have this coolness factor in software industry. Object oriented programming was cool some years ago and then it was distributed computing and then it was the internet programming and then Java. For programmers, same goes in smaller circles. Concepts and frameworks get 'cool' and then 'uncool'. Agile, TDD, naked objects, hibernate, IOC, spring, protobuffers...

All this 'coolness' causes a rabbit in the headlights effect on programmers. When something is cool, everybody uses it, but do you really need to? I just had a chat with one of my esteemed colleagues. Basically, we need to move some data over the wire and were considering, as you would these days, protobuffers. Then we realised; actually, the data we are trying to move has very simple structure, composed entirely of primitive types all in one class. Also, the structure is fixed. A simple toByteArray method or even default Java serialisation does the job.

So keep breathing, blink a few times and move off the road.

The death spiral of refactoring

Surely you must have seen this;

You are leisurely cruising your beautiful code. Then suddenly you come across a bit that does not feel that great. You think, ‘Right, it is time to restore the universal harmony of the code flow’. You have a better idea and start to pursue it. Code along for a while and suddenly you start to get flash backs of the time you had exactly the same idea (typically a few month back). You already coded it and it did not work for some reason that does not occur to one at the first look.

How to avoid this? Well surely you can consider not re-factoring working code, which is always good practice.

What I do is leave notes to myself:-

//NOTTODO However appealing it looks, doing blah blah blah does not quite work as for such and such

So rather than wasting valuable time, I check a few other things.

What is your favourite programming practice

People talk about programming methodologies, processes, test driven development, extreme programming etc. Most of them quite religiously. Youth these days are born into this stuff.

But we still see very poor code. Test driven, agile developed rubbish.

Why?

A lot of people miss the essence of a good program:- a good abstraction.

At times of OO there was more focus on getting a good abstraction. Trying to come up with the correct objects used to lead to better abstractions. People talked about crc cards, design reviews...

Then the design stuff got a bit out of hand with uml days. We started to have architects that only design and slave programmers that only program. Then came agile programming to remove useless upfront design. But somewhere along the line, focus on good abstraction is lost.

If programming is like climbing a mountain, a good abstraction is a path around the mountain, gradually increasing the altitude. A bad abstraction is attacking the mountain head on. You can 'force program' to completion, but what you end up with will be very hard to understand and maintain.

If your code is not flowing, if you are inventing additional, after thought mechanisms to keep it under control, may be it is time to take a step back and revisit your abstractions.