29 outubro, 2011

Top Ten Idea Killers in Software Development


Software engineers start out as being curious, enthusiastic and gung-ho about getting things done. Somewhere along the way, they butt heads against a world that doesn't understand software development: systems that count engineers by numbers, productivity by lines of code and quality by process; a world where software development is a "risk-management" bureaucracy rather than a creative endeavor that can solve customer problems.
Unfortunately, many engineers consider this a wake-up call to shed their energy and adopt those bureaucratic ways, convinced that they have stepped into a new, adult world of "management". Some who manage to resist that misstep become disillusioned and don the garbs of martyrdom, ascribing every failure to something that management did or did not do.   
If you are a software engineer, or an engineering manager, here's a list to help you identify if you still retain your software development genes or have morphed into someone that brings out a worn out list of cliches to robotically throw into every meeting, killing every idea and the morale behind it:
10. "This is good enough" : The fact is that nothing is ever good enough, least of all software. It may be good enough for today, or this release, but if your product has had the same problem for the last decade 1, some other company has already taken your customer away because of this feature. Fix it before you reach the point where you cannot.2
9. "This is how it was always done": This is an anachronism in any competitive, rapidly changing field but particularly in software. Software companies are not like automobile companies that can set an assembly line in place and forget about it for a hundred years. Oh, wait-a-minute! Even automobile companies cannot do that anymore! Today's problems require a new set of solutions because in an industry fantastically bound to Moore's Law, machines, along with people's expectations from them, set a terrific pace of change.

8. "There isn't enough time to do it right": This is how you get into Technical Debt; some of it may be inevitable due to business pressures or working with a new piece of hardware or technology. As long as you repay this debt in the immediate future, this is part of the process; but if this is how you avoid making the right decision and the responsibility that goes with it, you are not being true to your engineering origins.

7. "This requires core architectural changes": What doesn't? Ideally, a well-designed piece of software should be flexible and amenable to changes as the product develops. But as we've said, demands on software change rapidly and every piece of software written will need to be rewritten. This is the nature of the work, not an anomaly to be used as an excuse!

6. "Management has not prioritized it": I always want to ask: what exactly hasn't management prioritized -- making a good product? writing error-free code? reducing bugs in the field? making the customer happy? Agreed that sometimes we inherit legacy code and there is juggling to be done between fixing what exists versus writing new code but this is a specious argument as we will see below. Suffice it to say that engineering needs to set and execute its own priorities, however small,every day, instead of waiting for some giant, magical mandate from above, becausethat's never going to happen.

5. "There is already a lot on our plate": This is one of those nonsense tautologies that add nothing to the discussion. The focus is no longer the idea or how it should be executed but some longstanding grouse about 'having no resources' or some customer's bug list. Of course you have a lot on your plate! You are being paid to have that stuff on your plate -- start chowing down!

If an idea is worth executing, its adoption should not depend on whether you have a lot on your plate; if you fill your plate at the buffet with junk and decide you can't have a desired dish because your plate is full, you have done two things wrong: you chose the wrong things to begin with and then haven't done the simple math that you have to throw the junk off your plate to get what you want. You don't kill the idea, you clean your plate.

4. "Our software is very complex; we have to be careful about making changes": Check another nonsense tautology off the list. What enterprise software isn't complex? Are you saying you are usually not careful when writing code? You are a software engineer -- you are expected to deal with complexity and be careful about making changes -- that's a basic requirement. If this is a reason we as engineers cannot execute an idea, we need to go back to relearn the basics.

3. "No one is asking for it": This reminds me of Henry Ford's wry comment "If I’d asked people what they wanted, they would have said 'a faster horse'." Human beings are incredibly adaptable -- they will live with anything, including, as Ford observed, horse manure. If you give your customers a substandard product, they will live with it. But remember that humans are incredibly fickle, too; an idea you kill will only bloom in another company's garden. Being sloppy just because our software is "sticky" -- short for "the customer hates us but can't change because it's too much work" -- is setting the bar at a level that's not worthy of a true engineer.

2. "We have to have consensus": This is at number two for a reason -- it's a seemingly innocuous statement with noble intent that is insidious and on closer inspection, meaningless in the software context. Consensus is given undue importance in everything from design meetings, SRS/SDS3 reviews, documentation, QA practices etc. Software development is an expertise-driven exercise. Someone has spent years studying, learning and working in a specific field, and to not defer to that person for the final decision is to waste all that expertise, not to mention deliver a bad product, demoralize the expert, adopt the safest and most timid way and most insidious of all, diffuse accountability.

A group decision is a way to duck responsibility for the outcome. "We all decided together" is a way of saying "No one is responsible". We have a presidential system instead of a parliamentary system for a reason: the congress advises the president but the president makes the decision. Unless the decision is so obviously horrendous that 2/3rds of congress decides to override the decision, the president's decision stands. This is the only way the buck can stop at the president's desk.

And the #1 idea killer in software development is
1. "It can't be done": There is nothing that cannot be done in software. Non-engineers kid around with "It's only software, right?" as a way to gently provoke engineers but it's true! It is indeed only software. Engineers should respond with specifics of what it takes to implement rather than say something cannot be done. A statement like "It will take 15 engineers, with individual licenses for software xyz, with 30 Model ABC machines, each with 2 TB of storage with at least 250GB in SSD storage and 5 QA personnel for a period of 1 year to deliver this software" instead of "it can't be done."
Everything can be done; let's get into that mindset first. The rest will fall into place.

Footnotes
1. Anyone who has worked on enterprise software can give you a long list of "known bugs" that have been around for more than a decade
2. Sometimes you cannot because too much code has grown around the defect and changing it is just too darn difficult at this point; or because the software died under the burden of too many such defects; or you no longer have a job because the company folded. It happens.
3. Software Requirements Specification/Software Design Specification

Fonte:  http://www.computer.org/portal/web/buildyourcareer/Nosce-te-Ipsum/-/blogs/top-ten-idea-killers-in-software-development

28 outubro, 2011

Fábrica de Software e as dificuldades de TI

Vivemos num momento complicado no mundo do desenvolvimento de software. Sou desenvolvedor há um bom tempo e espero um dia ver essa indústria funcionar de maneira sadia, mas isso está demorando muito!

Continuo vendo pessoas que pensam na TI como um empecilho e não como uma solução para diversos problemas, mas para isso acontecer precisamos entender as dificuldades inerentes das próprias tecnologias utilizadas, compreender e domar, é isso que eu acho que deve ser feito, obviamente não podemos perder a visão do negócio, mas precisamos equilibrar os dois, e não valorizar demais o negócio e desprezar as tecnologias e por conseguinte a qualidade.

Penso muitas vezes o quanto o mercado de software mudaria se pudéssemos mensurar o custo da manutenção, mas isso não tem mudado muito. Isso acontece por dois motivos, primeiro porque é realmente complicado medir o custo de um software em manutenção e segundo porque não se quer.

Para medir o custo é necessário uma boa organização interna para saber o que deu errado, mas acima de tudo é necessário uma visão técnica e não de negócio para isso. Como saber se o código entregue estava realmente bem feito e de acordo com as expectativas? Daí vem a falta de desejo de medir, gerentes em geral só trabalham com os custos do desenvolvimento, uma vez terminado, o custo de manutenção fica mais restrito para a parte técnica saber o verdadeiro esforço, um gerente perderia voz e entraria então o conhecimento técnico para dizer de fato quais os problemas encontrados.

Para desenvolver um produto nada como diversas horas extras para alcançar o objetivo, mas depois de terminado, os gantt charts são atualizados com os custos de manutenção?

A terceirização promete eliminar os problemas do desenvolvimento do produto, mas nunca eliminará os custos de manutenção e é aí que mora o problema, achar que todos os sistemas são iguais é um erro recorrente na área e manter um produto que foi desenvolvido por pessoas de empresas diferentes, será sempre um desafio. Devemos usar as famosas fábricas de software com muita cautela, insisto em dizer que produtos cruciais devem evitar essa abordagem e quando não houver outra solução, acompanhar cada passo que é dado pela "fábrica", por passo me refiro ao código!