just4fun and profit

denuncialo_en_internet.jpg (JPEG Imagen, 800x408 pixels)

2009-04-21T23:42:17.181Z

So you've just been hired by an IT department... ‎(Software Engineering Tips)‎

2009-08-07T06:54:10.029Z

So you've just been hired by an IT department...

and it's your first job. Here's what they didn't teach you in college.

Nobody knows what they are doing

The theme of this entire web site, and not by accident. Your manager and his manager and his manager and so-on have no-clue what they want or how to get it. They will give you a set of specs that--from all outside appearances--seem set in stone. But no sooner than you deliver a program built to spec than they will argue it wasn't what they really wanted. They are relying on you to make them see what they want, and the cost is the sacrifice of a lot of code and hard work. "Oh, but I need to change the quantities on the original purchase order" is the kind of remark you're going to hear long after you have designed--and had them approve--an architecture that makes line-item quantities immutable. Get used to it, because the bottom line is that 50% of your job will be about showing them what they didn't want, after all.

Agile techniques and Unit Testing were adopted to impress you, not to actually benefit from them

The only reason an IT department has for adopting any of these methodologies is to impress recruits. None of them survive the environment of IT. They will be paid lip-service and given token respect.

Agile and Test Driven Development don't really deliver, anyway

Sure, your favorite programming blog says they're critical for quality assurance and maintainable code. I call bullshit. These techniques might work at the companies managed by the guys who write books about Agile techniques and TDD, but they don't really work anywhere else. The reason is because all of these methodologies are name-branded, shrink-wrapped cribs of the way one particular manager is good at doing his job. Their personalities, instincts and taste mesh well with what they invented for themselves, and now they want you to think it's the way everybody ought to do it.

It would be more appropriate if they just came out and said "every project manager should be a clone of me," but that doesn't sell very many books and conference tickets.

What happens in the real world is that good managers cherry-pick brand, off-brand and homebrew methodologies to factor into their own style. A few ideas from Agile^TM here, a few Unit Tests^(R) there, a dab of Design Patterns^{(Pat. Pend)} there, mixed up like chocolate chips, nuts and marshmallow into a batch of Rocky Road ice cream.

Then there are the individual developers, whose competencies and skills will look like a scatter-plot. Some will require spoon-feeding and use up all of the QA time, and others will look like they're doing nothing but surf Reddit all day yet commit more bug-free code in a week than you will produce in a year. To the former, expect them to be all over Unit Testing and Agile like white on rice. To the later, expect them to roll their eyes at the same.

If they don't use source control and bug tracking, hand in your two weeks notice

If this is your first job then you definitely aren't being paid enough for that shit.

You will live and die by these two tools, because:

someone in your department will fuck up, and
it will be your job to fix it.

Source control gives you the means to undo a major fuck-up, and bug tracking is the tool you will need to juggle all the fuck-ups that will happen concurrently.

The seller of a popular bug tracking system (and the one I use, incidentally) suggests that you should try to inject these into an organization grass-roots style by adopting them yourself, just for yourself, and letting them sell themselves to the rest of the company. But viral marketing isn't your job, and these two tools are so basic that they are signal factors: if the organization doesn't already have them then there's something wrong with the organization. It would be like going to work for a company that doesn't have bathrooms or a coffee maker; you shouldn't be thinking about bringing your own, you should be thinking about finding another job.

If you can work uninterrupted, you're lucky

IT departments are slaves to the whims of business, but remember that this is what pays the bills. If an opportunity comes to sell in a new market and it means handling ANSI X12 EDI over a VAN with a 50-page spec per message type, then it's probably going to interrupt whatever you were doing at the time. As you're in the middle of doing that, an existing business partner dumps a new requirement on you to handle two new message types with an October 1st deadline, wrecking that lovely schedule you drew up. Tough beans. Get them done and move-on. Yes, multitasking makes you stupid and the task-switching gobbles up hours of your time. The boss also knows this and is tired of hearing it.

If you were working for a software development firm where the software is the business, then such a muddle would kill the company. But you're in IT. You are not working at Microsoft. "I said Sizzler, not Google," and you're probably working for a company that makes its money by filling tractor-trailers, or putting bums in seats, or shoveling french-fries into fat people, or whatever. If this is so then the efficiency of the company's programmers will be a low priority.

If you have a dedicated QA staff, you're lucky

QA managers, testers, unit test developers, etc. are not seen until a department grows to 20 or 30 programmers. If your department is smaller than that and you still have any of those, then you're lucky. Otherwise your QA will literally be the field itself.

If your users are all in a different building, you're lucky. If they have been trained to take screenshots and email them to your bug-tracking system, you're lucky.

But if the company's attitude is that it's okay to burst into your cubicle whenever they feel like it, then you need to disabuse them of that notion as fast as you can. Post a sign outside your cubicle that says "SEND EMAIL TO FOGBUGZ" or similar.

The company started by hiring freelancers, and they were morons

Before the company was big enough to have full-time programmers on staff and a real IT department, they hired freelancers and consultants to develop their inventory, payroll, order management system and so-on. All of them were morons. It's not that they're stupid people, but the job itself--the job of being a contract programmer--creates an abstract entity who is a moron.

Why? Because it's impossible to show the value of refactoring and documentation to a CEO.

Remember I said that nobody knows what they want. Now say they've hired a consulting firm to design their inventory control and the consultants sit in on dozens of meetings, take notes, nod their heads, tour the building, look at the products, produce endless specs and proposals, then sit down and pound out code. Suddenly a zillion gotchas and change requests wriggle out of the carpet like slugs and maggots. The changes are made, but each one compromises the design in some way. Normally you'd iron-out those wrinkles with a good bout of refactoring, but these consultants are on the clock, and when the first bill arrives the CEO is going to want to know what features he's just paid for.

Imagine the conversation between the consultant and the CEO. "What's this line item for?" Techno mumble-jumble in reply. "What do I get for it?" Abstract and immeasurable concepts of goodness. "Take it off! I'm not paying for that!"

So consultants and freelance programmers don't do much refactoring. Once the contract is over they move on to the next job and forget about what they wrote. When something breaks, they start the clock again, hack and hack and hack until it works, submit their invoice and bugger off.

The person behind the role may be highly intelligent and competent (rare, but it happens), but the role makes them a moron. Sometimes they were morons to begin with, and the role makes them even worse.

Now you've inherited all that code and you get to fix it and extend it, and maybe--because you're salaried--spend time refactoring it.

Make friends by writing good code. Make promotions by listening and sympathizing

Your co-workers will love you if it doesn't suck to perform maintenance on your code. For this you need to read everything about programming that you can find and think critically about your own code. Imagine a stranger is reading it and write like you want to explain how things work.

To make a promotion, listen and sympathize with your boss's boss--to the people who are making the feature requests. Nothing scares a non-programmer more than a computer because they don't understand it and yet their business depends on it. Show them you understand how they feel, and when they ask for something that's ridiculous do not turn into a passive-aggressive jerk. Maybe they don't know what they're asking for, but they do know they have a problem. Try to find out what the problem is and propose an alternative that is actually helpful and would satisfy their need. If you do this then they will love you and never want to get rid of you.

This is not "brown nosing", this is babysitting.

Adding parameters to a post URL? : javascript

2009-03-17T20:46:37.469Z

document.frm.action = 'subcategory_select.jsp?id=5001&categoryId=1&subcategoryId=1206" with some posted data boolean1=true';
document.frm.submit()

danieltenner.com — Starting up with afriend

2009-03-11T19:05:27.558Z

Starting up with a friend

What could possibly go wrong?

Posted on March 11, 2009

by Daniel Tenner

in Start-ups

It seems like a fool-proof plan: start up with a close friend. You’ll get along (obviously), and you’ll get to share the exciting, fantastic, scary experience of starting up with someone you care about. It’s not a bad idea, but there are a few caveats that you should be aware of before you proceed¹.

When I started my first company with one of my closest friends, I expected things would go very well between us. We understood each other in ways that would take years to build up (and did take 10 years). We knew each other, and we knew we could rely on each other. We were prepared to have many surprises along the way — starting a business is always going to be a scary adventure.

What we weren’t prepared for was that the main problem would come from us and the dynamic between us.

What happened, in brief

I’m not going to go into all the details of what exactly went wrong, for a number of reasons (among them, it would be a one-sided account and inherently unfair on my friend and first cofounder). The long and short of it is, we had different expectations about the business. I left my safe, comfortable corporate job to work on it, so I needed it to succeed, or else I would find myself back in the corporate world. By contrast, my friend had already started several companies and was comfortably well off, so he didn’t have the same expectations and requirements.

It turned out we have a different definition of “the business isn’t working out”. For me, it was working out if it was making enough money to cover my expenses. For my friend, it wasn’t working out unless it was making enough money to also add to his existing wealth and thus justify the time and effort which he poured into it. Both those views were correct, but because we knew that we understood each other, we didn’t realise that our views were different until that difference had grown into a huge misunderstanding.

This core divergence of views could have been resolved easily if we’d known about it and discussed it ahead of time, but we didn’t know about it, so it festered and turned into dozens of other misunderstandings, so that by the time it finally became clear what our main divergence was, much of the damage was already done and it was entangled in a huge mass of emotional misunderstandings².

This almost cost us our friendship. We got through this thanks to the help and mediation of another very good friend, who helped us to communicate to each other how we felt, so that we could move forward together rather than against each other.

I’m glad to say the mediation worked, and we’re still friends (perhaps even stronger than before). Nevertheless, I learned some important lessons from this.

1. Make your agreements explicit

The first lesson is to keep agreements explicit. It’s not enough to think that your friend understands what you think: make sure he does by discussing it openly with him. As my mediating friend phrased it, “unspoken promises” have a tendency to turn into broken promises (which are always hard to swallow). Avoid unspoken promises.

Here’s an example of a really bad thing to keep implicit: “We’ll only call it quits if the business is bankrupt and can’t raise any more money.” The promise here is that we’ll keep going until the very end. This may seem obvious to one party in the business, but it may not be so to the other. One partner could, for instance, feel that the time to call it quits is when the business has 3 months of cash flow left. Another may feel that it’s worth going deep into credit card debt territory before giving up.

Don’t make this mistake: keep those agreements explicit.

2. Detail your agreements

Once you make some agreements explicit, it should become clear that you need further discussion to figure out exactly what your explicit agreement is. Don’t be afraid to do this. It’s not “too early to discuss this”.

Here’s an explicit agreement that’s not detailed enough: “We want the business to make a lot of money”. Really? How much are you happy with? 10’000 pounds a month? A million? What is the definition of success? It’s almost certain that you and your business partner have different views as to what “a lot of money” is. Being on the same page about what you expect out of your business will ensure that you don’t pull in different directions when things are going well. Think of how mortifying it would be to find out that your partner wants to pull the plug when you think that the business is successful.

3. Don’t be afraid of discussing the bad stuff

There are a number of subjects which seem almost embarrassing to discuss when things are going well. For example, “What if one of us decides to pull out?” Your first reaction to this topic might be “What? We’re barely getting started, and already we’re talking about what happens if one of us pulls out?”

The reality is that people’s life circumstances change through time. They get married, or decide to leave the country, or get engrossed in a different pursuit, etc. Many things can get in between a founder and his start-up. Similarly, many things can go very wrong with a start-up. When those things do go wrong, or when one of the founders decides to pull out, is not the time to discuss these things. You need to discuss them with a clear head when no one is thinking of pulling out and the business looks healthy and hopeful.

When you discuss your start-up’s future, do not be afraid to talk about the disaster scenarios. Also, when you negotiate what will happen if a partner quits, don’t be so sure that it won’t be you.

4. Write things down

There are two reasons to write things down: first, people’s memories of conversations are faulty. Writing things down also ensures that there is no disagreement, later, about what was decided. You don’t need a long document for this — even just one or two pages describing your agreement is enough to avoid later misunderstandings.

The second reason is that people may think they have reached an agreement when in reality they never agreed about the details. Once you put something in writing, you give it a certain air of finality that teases out those last remaining disagreement. Basically, putting an agreement in writing is like putting a new piece of functionality in code. Until it exists in that form, it’s just vapour.

Halfway through my misunderstanding with my friend, we thought we’d figured out a way forward. I wasn’t sure that we were both thinking the same thing, so I made the effort to put it in writing, in the form of a business plan. When my friend read it, and understood more clearly what I meant, he recanted, and the agreement fell through. It’s a good thing that it fell through, because it would likely have resulted in even more problems later on if we’d gone through with it based on our flawed understanding of each other.

5. Don’t make it work at all costs

Yes, I know this is your friend that you’re starting up with, and this is your great opportunity to start your own business. However, if, in those discussions, you find that there’s an intractable disagreement, don’t fall into the trap of thinking that the most important thing is to smooth things over and start the business.

Starting up with someone is almost like marrying them (temporarily), in a way. You’ll be talking to them almost everyday, and possibly even more than with your significant other. You’ll be working on a “baby” (your business) for many months. It’s a big commitment, basically, and much like any other kind of significant commitment, you shouldn’t go into it if you think there are major problems, because those problems will only get worse.

6. Don’t assume things will get better with time

It’s easy to rationalise away big problems by assuming that things will get better with time. In some cases, they will, but in a majority of cases, they won’t. What this means, for example, is that you shouldn’t assume that your inexplicably small share of the business will magically grow to 50% later on. This is even less likely to happen if the business is working well (if the business isn’t working out, chances are it doesn’t matter anyway).

Sample questions

This article wouldn’t be complete without a list of questions that you might go through and discuss with your cofounder. Use them as a guideline or as a checklist, as you please.

What do we both mean by “the business is successful”?
What do we both mean by “the business is not successful”?
What happens if one of us needs to voluntarily pull out, for any reason?
What happens if one of us cannot work on the business anymore, for involuntary reasons?
What are the conditions under which we’d call the business a failure and pull the plug?
What is plan B for each of us if we do pull the plug? Are we both prepared for that plan B?
What do we expect of each other, both in terms of responsibilities and in terms of attitude and effort?
What is and is not an expense? What is the maximum amount someone can spend on an expense without checking with the other? (from Sebastian Marshall)
When and how will profits be distributed? How much will be reinvested? What will the reserves be? (from Sebastian Marshall)
What happens if one partner needs cash and the other wants to reinvest it into growth/expansion? (from Sebastian Marshall)
How will you handle it when (not if) the hours each partner is working are unbalanced? (from Sebastian Marshall)

This is not a final list by any means, but it should at least provide some starting points to make the implicit explicit. If you have other suggestions, please do add them in the comments below.

Conclusion

I don’t regret starting that business with my friend, but I do regret not clarifying those kinds of questions upfront. It would have saved me a lot of worry. If your business is struggling, you don’t need the additional pain of seeing your friendship unraveling under the stress of accumulated misunderstandings.

So, do yourself a favour, and set out to:

Make your agreements explicit so that you don’t break implicit promises
Detail your agreements so that your promises are clear
Don’t be afraid of discussing negative scenarios, so that you don’t add the stress of misunderstanding to already bad situations
Write things down so you’ll remember
Don’t make things work at all costs, so that you don’t spend the next years living with a deal that’s not acceptable to you
Don’t assume things will get better with time, so you’re not surprised when they don’t

I hope this helps others. Your comments below are much welcome.

¹ It’s worth adding that this advice can be useful for any kind of adventure, not just business. However, given the propensity of businesses to crank up the pressure to diamond-producing levels, and what can often be at stake, it’s particularly important in this context.

² Although this sounds like a barely mitigated disaster, I must add that, on the whole, the business was a success (it made money, I learned a lot from it both about myself and about start-ups, and it provided a jumping board from which to start my next business). It wasn’t as much of a success as it might have been, and there were some times when it looked like it might turn into a small disaster, but on the whole it turned out reasonably well.

Historia de un Viejo Informático. El Cobol. Bonus Track: el “Virus del Milenio”.

2009-03-02T21:04:15.785Z

Algún iluminado, inasequile al desaliento, llegó a proponer que al Cobol Orientado a Objetos (OO Cobol) se le cambiase el nombre a “ADD 1 TO COBOL GIVING COBOL”, que es la traducción literal a Coboliano del término “C++”, puesto que éste último nombre de lenguaje había tenido tanto éxito en este entorno del OO… Pero parece que pocos entendieron la gracia, y no tuvo éxito la propuesta. ¡Qué cosas!

Strategy Letter IV: Bloatware and the 80/20 Myth - Joel on Software

2009-02-12T00:14:54.087Z

A lot of software developers are seduced by the old "80/20" rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.

Libertonia || No está muerto lo que yace eternamente

2009-02-11T22:48:55.991Z

Basicamente, las cosas nacen, comen (si, libertonia se comió a dos usuarios, yo lo ví), crecen, se reproducen (de donde creeis que salió sinner) y mueren. Quizás este proceso no sea exactamente así, y donde decimos reproducirse, podemos decir forkearse (meneame dicen que es clon de digg, yo digo que es el fork involutivo de barrapunto).

Bueno, me estoy yendo por los cerros de Úbeda, pero la gran mayoría ya entendeis por donde van mis tiros. Las cosas no se mueren solas, los usuarios dejan de usarlas y quedan muertas (Excepto algún nostálgico que vuelve cada cierto tiempo y dice: levantate y anda).

Lo que yo quiero incidir hoy, no es la muerte de ciertas webs, es la muerte de una generación, la generación de descubridores de internet y el software libre, porque, quieran o no, van de la manita. Hoy ya no es necesario hacer un artículo de como configurar xorg, o mutt o de como recauchutar el kermel para ganar medio segundo en el boot. Tampoco salen "bombazos" en internet como salían antes, esos maravillosos bbs, listas de correo de superfreaks y esas primeras bitácoras, que todo el mundo miraba con admiración, los periodistas del futuro les llamabamos.

Nos hemos colocado en una situación curiosa, aquella primera ola de descubridores está viendo como ahora invaden todo los turistas y lo llenan todo de basura. Ahora tenemos fanboys que dicen "ubuntu ruuls" y "ubuntu sax" por doquier. Ya sabeis a qué me estoy refiriendo, y el proceso es global. Lo que antaño fueron webs con gente con muchas ganas de aprender, y de enseñar, se ha llenado con gente deseosa de que creamos que son cools (porque trolls ha habido siempre).

¿Y es esto malo? En absoluto. Es el proceso natural de las cosas, y nosotros somos los viejos colonizadores a los que no nos gusta que lo que antaño era salvaje y desconocido, ahora tenga protectores de plástico y niños jugando a la pelota.

Y la culpa es nuestra ¿Eing? ¿Como que nuestra? Qué dices trukulo? La culpa es de esos putos mocosos que ... que no, que no, que la culpa es nuestra. Porque lo que queriamos aprender... ya lo hemos aprendido. Y ahora nos basta ojear un manual para saber hacer cualquier cosa. Ya sabemos, ya no tenemos necesidad de aprender unos de otros.

Historias de la ciencia | [Libro] Allegro ma non troppo

2008-11-20T23:04:07.810Z

La segunda parte del libro habla de lo que llama “Las leyes fundamentales de la estupidez humana”. Dice que los seres humanos poseen el privilegio de tener que cargar con un grupo más poderoso que la Mafia, que el complejo industrial-militar o que la Internacional Comunista. Un grupo no organizado que no se rige por ley alguna, que no tiene jefe. Son los (con perdón) estúpidos.

Y define estúpido aquella persona que causa daño a otra o a un grupo de personas sin obtener, al mismo tiempo, un provecho para sí o, incluso, obteniendo un perjuicio.

Explica que en todos los grupos, absolutamente todos, existe una fracción que llama épsilon de personas que son estúpidas. Esta épsilon no depende del estatus social, económico, cultural o cualquier otra característica. Todos los grupos (imagino que también incluiría a los escritores de blogs, así que no me libro; y a los lectores de blogs, así que tampoco vosotros os libráis) contienen esa fracción épsilon de estúpidos.

The Things He Carried - The Atlantic (November 2008)

2008-10-18T08:34:22.427Z

the TSA director, Kip Hawley, told me he respects Schneier’s opinions, though Schneier quite clearly makes his life miserable.

Claves WEP en 15 minutos o menos? EASY WEP FINDER v1.3b te lo pone fácil.....

2008-09-14T19:37:45.542Z

- 2. Versión independiente del EWF, sólo necesita de Weplab (incluido en el archivo de descarga) para funcionar.