7 Technical Management Techniques

Often it is the case, where team leaders and managers at software companies are ex-geeks that climbed the ladder to reach a managerial position. Well, "climbed the ladder" is really a misleading metaphor. First, who says managerial positions are higher, or better, than development positions? Some would argue the opposite. And indeed, in some companies, managers are offered optional rotations of management and hands-on R&D. Second, it is misleading since the less glamorous reality is that when companies expand, someone has to manage the newcomers, and those new managers where there at the right - or wrong - time.

Either way, geeks being geeks, social codes and human interaction were never their forte. How can they manage other people if they can't get a date without a facilitating website?

So, let me tell you some secrets. First off, the words 'Technical Management' in the title isnot what you think. You might think it's about management of technical people, but it isn't. It's really about the techniques of management. It's about knowing and using several technical and emotional rules, that would make the life of the manager geek (you?) so much easier, and would get results with less friction.

However, these rules and tips would not do the work for you. We are talking about Technical Leadership, but this post is more about the Leader part, and less about the Technical. The technical side deserves its own article, or maybe a book.

But there are some intersections. In your technical leadership, you can decide to follow either the Surgeon model or the Decider model. A Surgeon leader works as if he's a doctor operating a patient. He has a full staff - from nurses to residents - helping him do all the work by himself. The surgeon cuts, analyzes, takes a direction and on most cases, also stitches.

On the other side, a Decider (if I may quote someone) doesn't really have a concept or an technical ideology. It hears the opinions of the team, asks a lot of questions, and decides, this way or the other.

These are two well-defined extremes. As for you, you probably position yourself somewhere on this range - for better or worse.

When it comes to leadership, one needs to remember that management, as any other profession that deals with people, is highly complex and no recipes are to be found. One needs to understand the platform, the substrate for everything. And this platform is respect. This is what everyone is after. I think it's so important so I'll repeat it: respect is what everyone is after. Respect (self-respect included) cannot come without its sibling: humility. So if you have respect and humility, and you should, all other things will come easily. You will exert politeness, consideration and gratitude. You could give remarks and criticism without guilt and without being afraid of de-motivation. Most importantly, you will receive respect in return.

Now, after this short introduction, let's cut to the technicalities, to those techniques that would help you transfer this sought-after respect:



Technique 1: The Oreo

As Noel Coward once said, I love criticism just so long as it's unqualified praise. No one likes to be criticized. on the other hand, critique can be a gift someone receives as an opportunity for improvement. And you will need to criticize your guys since you are probably would have, sometimes, different ideas than them. So make them an Oreo sandwich: start with praises, put in the critique, and end with some more praises. Something like: the banner design is really cool. I think though the middle block should use Ajax, and not PHP as it is now. Still, overall the new node looks awesome!

Technique 2: No Buts!

But is a traitorous word. It tends to minimize whatever came before it, and sometimes simply nullify it. For example, when you say something like "listen, this piece of code is elegant, but the performance is bad". What the poor guy is left with is that the performance is bad. And thats taking a hit after investing so much thought in making it elegant (hey, elegance in code deserves another post altogether). Yes, she would survive, but why chip away in the motivation, if you could just use another word instead of the 'but'? What if you would just replace the 'bug's with an, say, and? Imagine now how the sentence would sound like, and tell me this is not a brilliant technique.

Technique 3: do you know the real meaning of assume?

Many a time we tend to think the other person is just an extension of our own self. This belief can be found in couplehood, as well as at work. And at those two places its exactly one of those beliefs that complicates matters. So here's the latest: The other person has different opinions, different priorities, different ideas. So when you assumed that she was going to do something in a certain way, your mistake was that you didn't convey this assumption to her and transformed the assumption into a discussion. Because when you assume, you make an Ass of U and Me. So Talk. Ask. Discuss. Just don't sit there at your desk and assume things will go right.



Technique 4: Praise in public (condemn in private)

With today's open space environment, the use for private areas is even more in demand. But dont make the mistake of using it for telling your man how much his work was good. Try to find any opportunity to praise him in public. And the opposite is true as well. Don't let him look like a fool. It's bad for him (or her), and it's bad for everyone else too: do you think they really believe its saved only for this poor guy? They are very much afraid for the moment it will get to them!



Technique 5: Responsibility goes with authority

Remember how they told us to delegate? well here's a quiz: how can you delegate and still be the manager? The answer, my friends, is that you can't. When you give someone the responsibility on a certain subject, he's the manager. And this responsibility must be accompanied by authority, too. The authority to make decisions, and the authority to make mistakes. Because those who don't make mistakes, are those who don't make anything. If you wan't to delegate, you should want that they will make some things.

Technique 6: Save the perfectionism for yourself

If I may choose only one technique, that would be it. Oh, how many managers did I see that thought their demand for perfectionism serves the cause. Here's a news flash: you aren't perfect. And your job, as a manager, is to understand that no one is perfect - but not to accept it. Remember: everything we have today, is a result of gradual improvements. So when the next engineer declares a done task, test it, compliment him, find the flaws, and continue to the next layer of improvements.

Technique 7 : Blame has three fingers pointed at you

This picture should be remember by everyone who feels the urge to blame:

As everyone can see, when you point a blaming finger and accuse someone for doing a stupid, stupid mistake, what really happens is that one finger does point towards the accused, one finger points up to bad luck, and three fingers pointing at you. Get that? you do the math.

Be humbler!

I think it's pretty amusing to see how many applications jump when you try to exit them and immediately ask you 'Are you sure?'. If you say 'yes' some would add 'Positive?' '100%?'

It's a clear case of developers' separation anxiety mixed with hubris. Guys:
a. Be humbler
b. Get a life!
If the user quits the application, it's most likely not by mistake. She really wanted to leave. So, you're not really helping the user by posing yet another message box, another movement of the cursor, asking for another click. Let her go and God Willing, she'll be back soon.

The charm of the bourgeoisie or: are we going backwards?

I'm not sure how wise to let the whole world know, but my favorite music recently has been Arabic and Italian. What a mix! Kudos to Last.fm. Their music collection and the radio stations they offer is just superb. Nagat El Shaghira is so cool!

So, it wasn't so surprising that when I saw Last.fm app offering on my XBox I clicked, installed, and immediately had all my beloved stations - Ya Habibi - on my Xbox. And from this simple experience, I have gathered several interesting insights.

First, that game consoles are becoming like the iPad (hey, it's Pad, not Fad) devices, and vice versa. The process of getting a Last.fm station was strikingly familiar to iPhone app installations. Select -> Install -> Run -> That's it. Hmm, and where is the keyboard? yes, the lack of a real one is also a surprising similarity. Oh, and what about the one-app-at-a-time concept? Wait a minute! there's something here. What's going on?

What has been going on is the second interesting fact. The Back To Basics movement has been with us for some time now. Operating systems, applications, and more than all, programming teams around the industry have started to focus again on Computer Science 101 - improving performance - and, God Forbid, on dropping features. Here, we see even a stronger tread backward: back to single-tasking operating system, back to primitive input devices, back to focus.

But this is only natural. And natural is the keyword here. Some of the user-facing people understood, finally, that computers has become too complicated. If not for us, then for our mothers. And it is our mothers, our girlfriends, and our kids, that they want to get a new market slice from. And for them, focus is one. They know, that they cannot drink and drive: they cannot multi-task. They can only do one thing at a time. They don't need 102 keys on the keyboard, if they only want to listen to some cool music. Just like when they flocked to google.com, it relaxes them - and me too - to see a single user interface control on screen. Simpler is super.

All of this is just another chapter in the inevitable journey of the PC from the home office into the living room. You have to make it friendly. Like the charm of the bourgeoisie, it is simply -- convenient. Simply friendly. As Nagat sings: Shabna, Shababna. Our friends, our youth. Friends must come easy -- and simple.

Forget performance. Let's add another feature!

Sometimes i think I'm a Benjamin Button kind of guy. As I grow older, I tend to do young, stupid things. For example, I have carelessly dumped my old Firefox in favor of a new Chrome browser. Then, I threw away my Palm Centro for an iPhone and reformatted my hard drive after my laptop slugged away for weeks. And as I done all this, I found out there's no turning back; and sometimes you feel you've lived your whole life in ignorance.

Google has marketed its browser as the fastest browser around today. Even if the performance is not as good as they claims, the minimalistic feeling certainly makes you feel this way. Apple didn't have to market anything. The amazing 3D effects in the iPhone's user interface and the smooth application performance market themselves. With current Vista performance I tried linux a few times although I quit it when gopc.net didn't allow me to install any applications.

All of these performance upgrades have one thing is common: out: new features; in: a lot of performance boosts. And here's the big question about all these performance upgrades. Where have you guys been all of those years? Have you forgot about us? Have you been deserted in the feature-land with all bridges burnt? Sometimes it makes me wonder. For years, Microsoft have added more and more and then more menu items on its Office applications - just enough to confuse you and obscure the real important ones. And who remembers the 'Offline pages' feature on early IEs? or the newsreader that came along with them?

I can't blame all those product managers who succumbed to the feature pressure. The "just throw more hardware at it" approach used to work on some situations, and was definitely enough sometimes. And Moore's law predicted that this trend will continue, maybe ad-infinitum. One might think, that it didn't reach the good developers. Well, you are right about the good ones. But all the rest - and more so, their managers - completely forgot to ask the right questions and never got the time to architect it right. Let's get it out there, fast, they said, and then let's get the next version, too.

But not any more. In a competitive environment, finally, finally, some companies are making products that at last gives me the feeling that I'm sitting next to a modern computer.
As we saw how Windows Vista is being actively cut back (can you imagine, features actually dropped); as we saw browsers like Chrome take off with an easy start; as the iPhone exploded with popularity, we knew: performance is back. And I hope it is here to stay.

The Dilemmas of Coding and the Architecture

I found a great blog about software architecture, and in it, a great post. What I like about this blog is the emphasis they put on the inherent conflict of the architect. The daily struggle with the developers who want to code now, and think later. The conflict with the managers - and the budget - who need to see the project delivered already. But more than all, it is about the fight with yourself. There are many such conflicts, some subtle, but definitely they keep the stress up and the spirits low. But in the end of the day, I sometimes feel, it's about the internal dilemma that involves the need to both manage your project - all of it, leaving no corners unwatched - and in parallel, the need to code the core architecture in the way you see it.

In Hebrew there's a saying: Tafasta Merube Lo Tafasta. Which means: if you try to catch everything, you will catch nothing. I learned time and again that you can't catch and control everything, and if you try to do so, it will have the reverse effect. On the contrary - you must let go, must delegate responsibility and give with it the authority to do so (because responsibility cannot go without authority). This, my friends (as McCain used to say) takes courage and calmness.

On the other hand, an architect must always code something in his project. Doing so will you can give you the feel for the code, and more importantly, the feel for your programmers. You will understand the daily hurdles they have to tackle, and it will free you from being the frustrated perfectionist, sitting in a managerial ivory tower surrounded by Gantt charts. That's why I like the name of the blog so much: Coding the Architecture.

5 frameworks every software architect should consider

One of the best things I like about developing software, is that every project is never like the previous one you've built.

That's right. But underneath all these systems, lies a set of common architectural modules, that every system should have. If you are an architect with a team of developers, or one developer with a team of managers, here's a list of a set of modules, frameworks and strategies you should have in mind. Not all of them would necessarily apply to you, but if I were you, I would at least think about each one. So if you are starting a new project - lucky you - from scratch, or coming to an old project with a mandate for change, here's a small checklist.


ORM Framework
Many programmers would start their efforts with writing a Data Access Layer. But nowadays, it is becoming increasingly clear that not only it is important to have a DAL, but a layer with objects (that is, classes) that maps to database entities. This is ORM.

A good ORM layer would have 3 minimal features:
1. It should allow automatic creation of objects. This is a nice example of the DRY principle. All the database-related fields are defined in one place: the database. With one click of a button - running a script - the classes are automatically created. This is code you don't touch. When you change one field in one table, you run this script again, recreating the whole body of classes once again.
2. It should support record CRUD - creation of a new record , updating of an existing record, and deleting of a record - all as operations availabe on the classes created.
3. It should know to deal with relations between tables. For example, if you insert a new order, you usually need to insert the order header table, with the master order details, and then a list of recorders int the child order details table. Traditionally, you would insert a new record in the master table, and then take the key that was created and use it as a foreign key for the child records. A good ORM would abstract that for you. For example, in Propel you would write:
...
$order->addOrderdetails($orderdetails);
$order->save();

and this last save() will insert the whole tree - even more than just one level deep, by the way

Tiered Framework
Once there was the 3-tier application, divided into the user interface (UI) layer, business logic layer, and database layer. The ORM is obvoiusly the database layer. Now the question is, what on earth is business logic? I always find this term a bit vague. When you build an application, what is not business? I think that the answer is, if it's UI, then it's not buisness logic. To add to that, business logic usually includes back-office processes such as automatic emails, pricing calculations, conversions, and more than all - decisions. For example, what form to present next.

What would such a separation give you? In web sites, this tiering would allow you to change the UI easily without changing the underlying, um, business logic. If you are talking about a desktop C++ application, then the benefits could include - how exciting - a cross platform for Mac. wow!

How to do it? in general I would leave it to you and your framework. I could say, though, that in my web sites the mechanisms I've created simply put all the UI related code in certain folders and classes, from which the forms and html have been built. In other applications I've used a tree-like module structure, where modules are interconnected by subscribing to events (more on that later) that each module can publish. The UI forms are simply modules in this tree.

There is a third way of separating the UI from the business logic and the db. Remember that you UI is a tree of control each containing smaller controls. For example, a form that contain a grid whose some of its cells contains a calendar control. Theoritaclly speaking, you could have a real tiered application who would have 3 tiers, but they would be separated on every level of the UI tree. In that scenario, you would have a business object for the form, that will contain a collection of objects for the grid lines, that will contain a collection of objects for the grid cells. Each of these object would have its related UI "tier" - meaning, a control that is bind to it. It would also have its bound database entity, but with tabular databases, the question is, how to represent the relations between the objects. And I have no clear answer for that. Maybe I'll try it on my next system.

Event-based Framework
I know this might be seen as an overkill to some, but hear me out. why events? This is simple. An eCommerce order form (AKA 'shopping cart'), for example, can be viewed as one module which includes the order date and number, the customer and a collection of the products on this order. The inventory, on another side of the system, is another major module holding all the products and their quantity in the warehouse. When an order is placed, you would want to update the inventory with the products sold, so the quantity in stock could be decremented. The simplistic way would be to have the inventory module exposing methods, and call them directly when the order is placed. The problem with that, is that some day - and you can count on this - some one will come up with a new requirement for more modules to be updated on an order. For example, an email module for sending an email to the manager reporting the sale. Now, for every new module that needs update, the developers will need to change the order module and add a new call to the new module. While the young, talented programmer looks at this as a non issue , we experienced architects know how much it can be simplified with an event-based framework. In such a framework, placing of an order would publish an event to the whole system. Not only would the Inventory module subscribe to it, but any new module that wishes to act upon this trigger, would subscribe too. So the amount of work needed to accommodate new requirements is minimized at least by half: there is no need to touch the order module. In reality, since software complexity tends to be exponential, the decrease in work is in much, much more.




When you do go ahead and write your publisher-subscriber framework, remember that you might take one more small step that will pay off big time later. As I explained in the "Tiered Framework" section, every system is inherently based on a tree-like architecture. Imagine, for example, that a sudden price change occured for one of your products. Different requirements arrise, one of them being the need to update all orders in queue that contains this product. A simplistic approach would be to search all these orders, find the ones needed a change, and update the prices.
But then, when a new requirement would arise, again we need to touch the source.

In a tree-based architecture, the orders are children of the root, and the products (also called 'order details) would be children of the orders.


An event would be published to the root. The products subscribe to 'price changed' event, and if an action needed, call the parent order (or better more, publish an event to the parent order) to change the total, the presentation, and do whatever else is needed on such event.

By the way, the same logic works in much more interesting applications - games for example. If a missile was fired in the area, all subscribed NPCs (Non Player Characters) would want to know about this event, so they could evade - and die, if hit was decided. Other modules would like to know that the missile inventory should be decreased, that the event should be reflected in a remote multiplayer session - in short, there is no shortage of wars to win with this frame of mind.



Cache Framework
Maybe one of the most important performance optimizers. From the L2 CPU Cache to the database's memcached, everyone should have a cache. To be honest, I'm still puzzled as to why it really works so well, and still at awe watching the magnitude of improvement. But it is clear now that this is the biggest performance boosters ever created. And every system should have its own Cache Manager class, which centralizes few important actions: from adding a value to the cache, to retrieving, invalidation, and - very important - single point of overall cache deletion

Error and trace Framework
It is sometimes amazing how this simple module often get ignored until the later stages of the project. But a clear definition at the beginning of the project can do wonders to your ability to find fast bugs and exceptions.

There are some nice open source pacakages that offer a nice set of features. But whatever way you implement it, here are a few key notes I believe worth repeating:
1. distinguish between tracing and error reporting. It is not the same. Tracing is used for the development team, or for very problematic client sites. Errors are something else - you need to always report them
2. an error is not a bug. If a function cannot calculate a price for this quantity, it might be reported to the user, but not an error. In my view, every error is an Exception. Something that no one foresaw.
3. Invest the time to get real time tracing. You'll thank me later.


Every software system is the unbelievable sum of its developers. These are some of the frameworks that will hopefully help them succeed, and their system to grow without collapsing under its own weight.

Views on Misearable Programmers and ORM

I think that there are miserable programmers. Those who need to deal with database issues, for one. At first it feels good - every new table connection is a added ornament to the party. Then comes another connected table. and another one. soon enough, it goes out of hand and everyone, from the project lead to the last programmer, is miserable.

So that's why we have the ORM. I love it. For each table, you get a class. So I've introduced it to one of the girls, and thought, that would not give her a chance to act miserably. Oh boy, was I wrong. It turned out, that the ORM just made this too easy. Because the connection to procedural programming language is so direct, she accessed the database as if it was an array in memory. one line gets the first table. Another line iterates on the records, and for each one gets the child record. That's how you can get a perfect siesta, because you can get some sleep while the loops finish running. So lame.

On the other hand, the ORM we were using - Propel for PHP - was not supporting easily a custom join SELECT (and I doubt if any ORM would). So the idea that saved the day was to use a VIEW. With views, you get the good of both worlds: the ORM treat them as tables, so you get a class per table. and the performance would be optimal, since all the joins are done on the SQL level. And the best: you dont need to write a stored procedure.

This reduced the code level a little - from 20 lines, to 5. The performance is obviously better. and now she's much less miserable, and so am I.