Knowledge (De)Generation Process

Alternate titles:
- Corporative (Dis)Information System.
- Meat grinder.

In any social arrangement which pursues collective goals –an organization– specialization is generally a good thing. You see, if you are a mafia leader it's probably not a good idea to go around killing people in broad daylight, or dumping dead bodies in the river –although it might be fun from time to time–. You have to be a respectable member of the community to be able to run your organization and that's why if you find yourself in need of killing somebody you have someone else to do it for you.

That person in turn receives special protection from you, in order to make a living of something that's, well, illegal. On the other hand a mafia leader is usually great at negotiation, evasion, corruption, etc.; while the hitman is pretty good at killing, cutting and dumping. That's specialization right there.

It usually happens that you grow your team from an extremely well knit core into something that can handle multiple projects at once and then into a company, simplifying a-lot. When you have your company, odds are you'll organize (divide) it in some kind of areas, which can take various names. Under the hood, whether you like it or not you are creating silos, and silos create inefficiencies. Period.

Let's try to think out of the box –buzz-phrase– and find a way to not create them at all, instead of managing them.

How good you are at managing those inefficiencies and how good is the people working in those silos will probably make you a better company. Leveraging the ideas found in Peopleware we can safely state that a company with better people, is indeed a better company.

The problem with silos is that the inefficiencies generated are not linear at all as they can range from small misunderstandings to complete failures in the implementation of a corporate vision; thus rendering errors of orders of magnitude everywhere. This is mainly due to the loss and degeneration of information crossing between silos many times. I'm not going to go deeper into this, if you've worked in a company you should have seen it, and if not you're either blind or desperate to keep your job.

One could fill a whole library with management books that talk about how to eradicate silos or at least manage their impact, some of them very well written masterpieces. But we live in an age in which getting your company up and running get easier every day so we're seeing 100-year-old companies, masters in their respective domains, competing with 25 guys in a garage and loosing miserably.

Does that mean that they are idiots and the garage boys are the coolest thing ever? NO.

Such companies are to be imitated, we have a lot to learn from them specially when it comes to adapting to market changes. But they usually are very inefficient in some key areas, and it takes them a lot of energy to evolve internally.

So, what's the point in all this? Well, you're fighting against something you created. I believe that you should never create silos at least for the core of your business. It should be a core, very well knit team that has empowerment, vision and talent to do everything, from facilities to consulting. The rest of the services that are not core to your business should provide services to this core. And taking it a step forward, you could have many cores, with different visions and approaches to business. What I'm trying to convey here is that it is by far more efficient for your business to organize the company in horizontal slices rather than verticals.

High productivity teams have proven us this sort of thing works damn well, but they can scale. It seems to me that it should be easy and more effective to have a cloud –buzzword alert goes off– of them, and let them create their work environment, their offices, recruit their own teams, and maybe most importantly realize their vision, without having to fight internally. Good people fight internally, get frustrated and leave. Bad people stays, loves inefficiencies because it's an easy source of stuff to do that either is solved with simple bureaucratic processing or provides very good excuses for failure.

The Importance of Software Design (damn!)

If you just accept that any non-trivial effort in software engineering requires a deep knowledge of software design principles, a set of quite sharp minds, a lot of common sense and a good deal of trial and error; your life will be much easier and rewarding.

There's no such thing as: "Lets plan, break down the work, select the easiest/repetitive tasks and assign them to the junior people on the team". That just doesn't exist, or even better, it shouldn't exist, because if you ever find such a statement valid, I can tell you for sure you're doing something wrong.

If you've gotten this far, probably you're asking yourself either:

a) how could this guy make such a bold statement without any hard facts backing him up? or;

b) who's this asshole thinks he is?

The answer is quite simple. Software engineering has some very interesting similarities with other industrial production systems which are very useful to organize our work, but also some very specific differences that make it more similar to, say, oil painting. Keep reading, hopefully it'll make some sense.

One of these key differences lies in how easy is to actually build and shape your assembly line, the machines, the workers and all the parts of your production system. We could generalize and say that proper design does not leave any room for simple or repetitive work. If you do have repetitive work – J2EE, remember? – design is wrong. The process of crafting a new piece of software is all about design, solving new problems every time. Reusable components are very useful when user requirements repeat themselves, which is as common as many people like to believe.

What about the RAD tools then? Well, they are a bunch of design decisions that, hopefully for their makers and users, will fit a wide set of common/generic use cases, but as anyone who uses them seriously knows they save time upfront and tend to fall short in the long run – which is just fine.

Knowing that design takes time and brains saves money. A lot of money, and time and stress.

Does this mean that there's no place for juniors in software development? NO. But it's not like you would imagine where simple tasks are assigned to newbies, but more like the master-student relationships the artisans usually build. Juniors are supposed to solve the same problems as seniors, but guided by the laters and learning a lot in the process, bringing also new ideas and synergies to the table. This is the way that people really learn to create, the other way they will learn to copy and paste, or if they are good they'll get really frustrated.

So, to keep this short: If you are about to undertake serious software engineering in any form get you a good team, disregard or challenge anyone that sells super rapid ramp-ups, lots of juniors upfront, magic frameworks that only leave repetitive/configuration work to the dev team, concentrate on your business and users, be sensitive about them, be open to chat about business goals with your developers, build an engaged team, don't ask for a Gantt chart, embrace agile in your heart. You'll love the results.