Posts Tagged ‘rant’

Chestii utile de stiut in bucatarie

10 August 2009

Vad la teveu bucatari „de renume mondial” care fac prostii – cel putin in opinia mea de Stan Patitu’. Asa ca m-am gandit ca ce-ar fi sa zic eu aici ce si cum se face in bucatarie, si mai ales ce nu se face, din propria exprienta. Evident ca nu-mi vine tot in minte ce tre’ scris aici  deodata, asa ca probabil (in masura in care ma lasa lenea) o sa mai adaug cand si cand cate ceva.

Nu se baga cutitele in apa fiarta, si in nici un caz in foc, sau in chestii scoase fierbinti din cuptor. Se inmoaie otelul si  in timp cutitele nu mai tin ascutisul. Is unii care zic ca asta-i basm, da’de fapt e pe bune. Temperaturile la care se petrec modificari de faza in otel sunt unele dintre ele de sub 300 de grade Celsius, adica in Kelvin sub 600, ori daca bagam cutitul in apa fiarta il ducem pana la aproape 400 K, deci o temperatura relativ aproape de temperaturile de schimbare de faza. (Bineinteles, totul e relativ, ca temperaturile astea variaza in functie de compozitia otelului, da’  ideea e ca si incalzirea pana la 100 de grade Celsius e periculoasa pt. cutite.)

Nu se toaca vinetele cu metal. Se amarasc daca stau suficient de mult timp in contact cu metalul. La fel si ceapa: chiar daca o taiati cu cutitul, n-o lasati sa stea in vase de inox dupa ce e tocata. Inclusiv inoxul e suficient de reactiv incat daca ceapa sau vinetele sunt suficient de mult timp in contact cu el sa le amarasca.

Nu se sareaza carnea de la inceput cand se pune la fiert sau la prajit. Ramane mai frageda daca se pune sarea catre sfarsit. La inceput tre’ puse condimentele ale caror arome tre’ sa patrunda adanc in carne.

Nu se pun legumele la fiert o data cu carnea, daca mai vreti sa folositi si zeama. Din carne iese sangele, care se face spuma la suprafata lichidului. Abia dupa spumuiala se adauga legumele.

Nu se tin rosiile in frigider. Ce face rosiile bune si dulci e o substanta care se formeaza la cald si se descompune la rece. La fel si usturoiul: mai degraba seaca sau mucegaieste sau se strica in frigider decat afara.

Nu se umbla cu instrumente metalice in cratite teflonate, chiar daca-s de otel. Doar cu lemn, sau, cui nu-i face greata, plastic termorezistent.  „Teflonul” e un strat de plastic termorezistent in care-s prinse particule de teflon cam ca pestii in plasa (teflonul nu se lipeste de nimic, asa ca nu poate fi el de el aplicat pe suprafata vasului), si o paleta sau lingura metalica chiar daca nu de la prima utilizare pana la urma tot desprinde bucatele din stratul ala de teflon.

Nu se pune zahar (sau nu in exces) la pornit drojdia. Zaharul in exces omoara drojdia. Drojdia se porneste cu faina.  In aluaturi cu drojdie daca puneti sare multa obtineti acelasi efect: drojdia moare si aluatul nu creste (sau creste foarte greu si foarte lent).

Legumele pe cat posibil se spala inainte de a fi taiate sau curatate. Daca le speli dupa, se pierde o gramada din aroma si din ce-i bun in ele.

Agile development is mostly just hype (IMO)

12 Noiembrie 2008

Although there’s value in many of the techniques it employs.

For anybody not familiar with the topic: the root of all evil regarding agile development.

As a software developer, what I usually have to fight for is getting customers to pay for what they want (well, my boss does most of the fighting, but my support role is of such nature that I get to observe most of what happens in the process). With very few exceptions, customers prefer to be told the world can be programmed in two weeks and get a shabby and useless application when delivery is nigh, rather than be told it will take somewhat longer, and get a proper application upon delivery. And they never learn. You judge which is the more honest approach. IMO, agile development doesn’t support what I think is right (i.e. telling the customer right from the beginning what to expect). I’ll try to explain why I think this.

What the agile manifesto says:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

While I have no problem with the first statement,  I cannot wholeheartedly agree to statements 2 and 3. And I cannot accept that the only way to act according to statement 4 is by using agile methods.

Working software has a problem: unless there’s a reference to compare it against, the customer (well, most of them, at least) constantly changes his mind. Which is OK as long as you work with an unlimited budget and with no fixed deadline. Which is utopic in most cases in real life.

The same obstacle stands in the way of customer collaboration over contract negotiation. Of course you  can start collaborating with the customer, but if you’re an entity working for money, not for charity, somebody needs to pay for this collaboration. Due to a very broadly spread misconception, the customer usually is only willing to pay for the product, and often considers all the communication overhead you need to invest in getting a product right just some minor overhead you have to pay for yourself. Which is stupid: he wouldn’t treat a lawyer or an architect this way, he wouldn’t treat his own engineers this way, but it’s OK to handles software engineers this way. In my experience, customer collaboration works smoothly only after a negotiated process is set in stone by a contract. Just to make sure you get it: not the requirements for the software to be developed, just the processes to govern the collaboration.

Responding to change and incorporate change into the plan is what civil engineers (or airplane manufacturers, or ship builders, for that matter) do already for a long time. Their projects are even worse off than software projects. They last inherently longer, are usually a lot bigger from the point of view of invested resources, and as such on one hand changes are more likely to happen and on the other hand more likely to be a lot more expensive. Yet, they don’t rely on anything even remotely resembling agile methods in their processes. I surely wouldn’t want to fly in an airplane where some structural engineer patched the design and „implementation” just a day before the airplane got shipped, rather than going through an expensive and slow redesign process, followed by a thoroughly checked manufacturing and testing process. Surely I must be an exception – it is often the same civil engineers that are OK with a software built from patches all the way from requirements gathering to deployment, which crashes on them all the time (well, it’s more often their bosses, engineers tend to have a preference and a better understanding for the need of a more organized approach to developing something than management usually has).

Further, there are quite a few principles of agile development I also don’t agree with – I’ll pick only the ones I don’t like. (After all, there must be something good in agile methods if so many bright people buy into it, it just seems I don’t grok it, so at least some of the principles must be right.)

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Chances are, you just manage to bore him to death, if increments are delivered too often and without much visible progress. Or you get a rude reaction: nothing works, nothing of what we discussed is there (in spite of agreeing with the customer about the stories to be implemented before each iteration). I have seen both situations. Rather, I’d agree on some essential milestones right from the start, with clearly verifiable goals to attain at each milestone. It’s the way customers are used to do projects in other areas, it will be the most familiar way for them to work with you in a software development project.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

It all depends. If the customer is willing to pay for it, sure. Otherwise it simply doesn’t work, no matter how nice it sounds. And of course, no matter when changes get into the project, you need a proper way to assess cost overhead. Or you’ll be bankrupt soon (either you ask too much, so customers will stop doing business with you, or you ask too little to cover your costs, if you don’t have a proper cost assessment method – I have seen very few customers willing to pay on a time and material basis).

Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.

Sure. As long as you can afford this. In real life, however, you more often than not get management, labor market, company regulations, non-functional, non-negotiable customer requirements acting in the opposite direction.

The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation.

And also the  most likely way to ensure that two days after a discussion each part remembers a different conclusion. Which is important when the two parts sit on different sides of the table. Written communication, i.e. documentation, doesn’t have this problem. Not writing anything down in a maintainable way is the most successful method of quickly aggravating the customer, in my experience. However, agile developers argue against documentation, towards code without documentation. Do you know of any other engineering process working without documentation? I don’t.

Working software is the primary measure of progress.

Bullshit. It’s software that does what it needs to do is, software that just works isn’t. In fact, building a perfectly working system that does what the customer asked for but doesn’t do what the customer needs is one of the glorious ways in which quite many software projects fail. Close to zero bugs, only you got the requirements wrong. Tough luck. Of course, the next iteration will fix it. If there’s any budget left, that is.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Why would it be needed to keep up the pace indefinitely?  Software development is clearly an activity organized by projects – every customer expects you to eventually finish working on his app, and also expects you to make a prediction about that finish before you actually start working, or he won’t give you money. You just have to plan to keep the pace up until the project finishes. Event this is not needed, because work on a project is almost never paralelizable in such a way that the workload is constant from start to finish. But how can you name a deadline if you can’t even say how many iterations you’ll need, because you shun documentation and as such don’t have a scope definition to share with the customer?

Simplicity–the art of maximizing the amount of work not done–is essential.

Again, bullshit. I have seen this work in several organizations. They were maximizing the work not done at the expense of testing (did you notice the principles say nothing about testing, although techniques employed by agile development emphasize unit testing as one of the most valuable agile tools?), or by simply not getting parts they deemed unimportant done. Because they knew very well how the end-users used to use applications, this was not regarded as a problem by regular users, since the bugs or missing parts were getting discovered at a very slow pace, allowing them to fix them in due time, without aggravating the end users. But this approach still costs. Only the programmers managed to hide the cost of their sloppy work. This is no real economy. I’d rather stick to what Einstein said: things should be made as simple as possible, but not simpler than that.

The best architectures, requirements, and designs emerge from self-organizing teams.

If only bad software could tell stories! Think spaghetti code – it’s often done by self-organizing teams with a more than lean attitude towards codee quality. A nice architecture emerges from a programmer or a group of programmers who are able to do architecture properly. These guys are usually smart enough that management or whoever from outside has no chance to interfere with their architecture. The rest of the team doesn’t matter for architecture. It matters just for transforming this architecture into source code. If the rest of the team is so much less bright than the architects are, they will have difficulties understanding the design, and implement anything but the original design. Yielding a bad product, usually. One of the most important (IMO) aspects required for agile development is a homogenous and above average skilled team, which is seldomly the case in real life.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts  its behavior accordingly.

I don’t dislike this one, actually.  I just don’t like that agile developers make it _their_ principle. Also, I think it should rather be a permenent process, instead of something you only do at regular intervals.

My conclusion is that agile development was set up by highly successful IT consultants who owe their success to good marketing more than to skills useful to their customers. Sun Tzu said it quite some time ago: a good general is likely to go unnoticed, since it is highly unspectacular how he wins his battles – a good general usually only fights battles he has already won. A bad general, on the other hand, will take part in many spectacular and risky battles, and have only costly successes to show. The same with software: anybody is more likely to remember a project which got through ten successive iterations before it was barely usable, and call it a great and spectacular success, and not remember a project similar in all aspects, only that got it right right from the first delivery. Even worse: for the project getting it right right away, they’ll remember that it took a looooong time to develop, as opposed to the other one, which took three or five times longer to complete, but provided ten or twenty (unusable or incomplete) deliveries during that much longer period.

(Now ain’t I good at throwing stones?)