Seven Characteristics of Key Performance Indicators

1. Nonfinancial measures (not expressed in dollars, yen, pounds, euros, etc.)
2. Measured frequently (e.g., daily or 24/7)
3. Acted on by the CEO and senior management team
4. Understanding of the measure and the corrective action required by all staff
5. Ties responsibility to the individual or team
6. Significant impact (e.g., affects most of the core critical success factors [CSFs] and more than one BSC perspective)
7. Positive impact (e.g., affects all other performance measures in a positive way)

What does the architect do? How is an architect different from a senior developer?

These are some of the common questions that get asked over and over again in the industry. We will explain, from the exam developer’s point of view, these questions so you have that common understanding when taking the exam.

"The designer is concerned with what happens when a user presses a button, and the architect is concerned with what happens when ten thousand users press a button."

How to play the guitar

Teoria dos Jogos: O que é Teoria dos Jogos

O que é Teoria dos Jogos e como ela pode melhorar as suas decisões estratégicas? Teoria dos Jogos é o estudo das tomadas de decisões entre indivíduos quando o resultado de cada um depende das decisões dos outros, numa interdependência similar a um jogo.

Mas primeiro é interessante explicar o que não é Teoria dos Jogos: decidir qual carro comprar, por exemplo. Escolher um automóvel é uma decisão complexa pela quantidade de variáveis a considerar. Além do preço, existem a aparência, estilo, tamanho, motor, conforto, acessórios, etc. Para complicar, sempre há um trade-off: nenhum carro possui exatamente todas as características que você gostou. Seria bom se o carro A, como aqueles acessórios, também tivesse a configuração do motor do carro B. Você pode criar um algoritmo (mental ou via computador) para colocar todas as variáveis e pesos de importância (suas utilidades) e criar um ranking. Entretanto, o exemplo do carro é uma decisão isolada - a decisão é só sua e não há interferência de outros no resultado.



Já a Teoria dos Jogos estuda cenários onde existem vários interessados em otimizar os próprios ganhos, as vezes em conflito entre si. Por exemplo, imagine que em sua empresa você tem dúvidas sobre qual ação tomar para aumentar o seu lucro: reduzir o preço, lançar outro produto ou fazer uma campanha de marketing?

No caso de reduzir o preço, conhecendo a curva de demanda, se abaixar o preço em 3%, sua receita sobe 7% pois vai ganhar market-share. Você calculou a relação de preço versus vendas e, conseqüentemente, a migração de consumidores do produto concorrente para o seu. Mas e se seu concorrente reagir e também abaixar o preço na mesma proporção? Como conseqüência da estratégia dele, o seu ganho, antes imaginado como aumento em 7%, muda para uma perda de 5% pois não aconteceu como você previu.



O resultado (ganho ou perda) de uma decisão depende obrigatoriamente da movimentação dos dois concorrentes, tornando a tomada de decisão muito mais complexa. Por isso, você precisa saber quais são os ganhos ou perdas de cada combinação e identificar quais são os incentivos mais atraentes para seu adversário, sabendo que ele está imaginando quais são os seus ganhos para também tomar uma decisão.

Com essas informações e deduções, reduzir o preço não é uma boa estratégia. Então você imagina fazer uma campanha de marketing. Começa outro ciclo de previsões: como ele vai reagir neste caso? Ao se antecipar as ações do seu competidor, você deve repensar antes de agir e visualizar todas as implicações de cada decisão, e ele fará o mesmo simultaneamente.

Por isso, a melhor recomendação é: antes de tomar uma decisão, coloque-se no lugar do concorrente e imagine qual seria a reação dele dadas as ações e incentivos existentes. Simultaneamente ele fará o mesmo - entender quais são suas motivações e ações para que ele tome a melhor decisão. Este é ciclo sem fim: você pensa que ele pensa que você pensa que ele pensa que....

Teoria dos Jogos é isso: entender que sua decisão não é independente e ambos os ganhos dependem da combinação de muitas ações em cadeia até chegar em um equilíbrio. Este equilíbrio é o chamado Equilíbrio de Nash, em homenagem a John Nash Jr, prêmio Nobel de 1994 e que foi personagem de Russell Crowe no filme Uma Mente Brilhante, ganhador do Oscar de 2002.

Outras analogias interessantes sobre decisões interdependentes são o Dilema da Ponte e o Dilema do Vagão de Trem.


Teoria dos Jogos: o intuitivo agora sistematizado

Pensar no concorrente e nas ações-reações antes agir parece ser muito intuitivo. Você já pensa assim, certo? Então, por que precisaria da Teoria dos Jogos para uma atitude tão óbvia? Resposta: porque a Teoria dos Jogos oferece metodologias que organizam o seu raciocínio nos jogos do cotidiano com seu concorrente, chefe, subordinado, colega de trabalho, cliente, fornecedor, vendedor, amigo, esposa/marido, governo, consumidor e outros.

Nesta caixa de ferramentas existem alguns conceitos estruturados que ajudam na comunicação e no entendimento de como as pessoas decidem. Exemplos:

- matriz de resultados ou esquema de incentivos
- jogos seqüenciais versus simultâneos
- cooperação versus competição
- dilema do prisioneiro e equilibrio ineficiente
- equilíbrio de Nash
- estratégia dominante e backward induction
- jogos repetitivos e estratégia mista
- informação incompleta

Assim como várias teorias de administração ajudam a estruturar o seu pensamento nas decisões competitivas, a Teoria dos Jogos possui modelos formais e exemplos que facilitam o entendimento nas decisões interdependentes, além de facilitar a comunicação e treinamento dos conceitos como qualquer teoria formal. A base da teoria é colocar-se na posição do outro e raciocinar o que você faria em cada situação, modelando todas as interações com benefícios/prejuízos de ambos e daí tomar a melhor ação estratégica.

A Teoria dos Jogos, como disciplina independente, não resolve todos os problemas, mas apresenta vários insights para melhorar seu pensamento estratégico como um elemento complementar das demais Teorias de Decisões. Para se aprofundar e para ser um bom estrategista, é importante unir os conceitos das disciplinas de Estratégia, da Economia Clássica (como preferências e utilidades, resultado esperado, risco e incerteza, free-rider, assimetria de informações) e da Teoria Comportamental (heurísticas e viéses cognitivos). Neste último caso, quanto mais você souber quais são os incentivos e reais motivações do seu concorrente ou parceiro, maiores as suas chances de ganhar o jogo. A união de todos os elementos é uma grande forma para melhorar suas decisões estratégicas.

Fonte: http://www.teoriadosjogos.net/teoriadosjogos/list-trechos.asp?id=24

Night Terrors

Night terrors is a phenom that occurs in children between 3 and 6 years old.

symptoms:
- sleepwalking
- to scream while sleep
- scaring while sleep

causes:
- sadness
- greasy food
- lack of sleep routine

treatment:
- don't awake the children
- help them with the goods words
- follow a sleep routine

Night terrors doesn't leave memories and last for much time.

A Couple of Surreal Pictures

Improving Performance

The two factors that determine the system performance are as follows:

• Processing time—The processing time includes the time spent in computing, data marshaling and unmarshaling, buffering, and transporting over a network.
• Blocked time—The processing of a request can be blocked due to the contention for resources, or a dependency on other processing. It can also be caused by certain resources not available; for example, an application might need to run an aggressive garbage collection to get more memory available for the processing.

The following practices are commonly used to increase the system performance:

• Increase the system capacity by adding more raw processing power.
• Increase the computation efficiency by using efficient algorithms and appropriate component models technologies.

Introduce cached copies of data to reduce the computation overhead, as follows:

• Introduce concurrency to computations that can be executed in parallel.
• Limit the number of concurrent requests to control the overall system utilization.
• Introduce intermediate responses to improve the performance perceived by the user.

YAGNI

Logical layers are merely a way of organizing your code. Typical layers include Presentation, Business and Data – the same as the traditional 3-tier model. But when we’re talking about layers, we’re only talking about logical organization of code. In no way is it implied that these layers might run on different computers or in different processes on a single computer or even in a single process on a single computer. All we are doing is discussing a way of organizing a code into a set of layers defined by specific function.

Physical tiers however, are only about where the code runs. Specifically, tiers are places where layers are deployed and where layers run. In other words, tiers are the physical deployment of layers.

Pink Floyd HD Pulse Live at Earls Court 1994

You'd Better Writer a Effective Code - Java Effective

Creating and Destroying Objects
Item 1: Consider static factory methods instead of constructors
Item 2: Consider a builder when faced with many constructor parameters
Item 3: Enforce the singleton property with a private constructor or an enum type
Item 4: Enforce noninstantiability with a private constructor
Item 5: Avoid creating unnecessary objects
Item 6: Eliminate obsolete object references
Item 7: Avoid finalizers

Methods Common to All Objects
Item 8: Obey the general contract when overriding equals
Item 9: Always override hashCode when you override equals
Item 10: Always override toString
Item 11: Override clone judiciously
Item 12: Consider implementing Comparable

Classes and Interfaces
Item 13: Minimize the accessibility of classes and members
Item 14: In public classes, use accessor methods, not public fields
Item 15: Minimize mutability
Item 16: Favor composition over inheritance
Item 17: Design and document for inheritance or else prohibit it
Item 18: Prefer interfaces to abstract classes
Item 19: Use interfaces only to define types
Item 20: Prefer class hierarchies to tagged classes
Item 21: Use function objects to represent strategies
Item 22: Favor static member classes over nonstatic

Generics
Item 23: Don’t use raw types in new code
Item 24: Eliminate unchecked warnings
Item 25: Prefer lists to arrays
Item 26: Favor generic types
Item 27: Favor generic methods
Item 28: Use bounded wildcards to increase API flexibility
Item 29: Consider typesafe heterogeneous containers

Enums and Annotations
Item 30: Use enums instead of int constants
Item 31: Use instance fields instead of ordinals
Item 32: Use EnumSet instead of bit fields
Item 33: Use EnumMap instead of ordinal indexing
Item 34: Emulate extensible enums with interfaces
Item 35: Prefer annotations to naming patterns
Item 36: Consistently use the Override annotation
Item 37: Use marker interfaces to define types

Methods
Item 38: Check parameters for validity
Item 39: Make defensive copies when needed
Item 40: Design method signatures carefully
Item 41: Use overloading judiciously
Item 42: Use varargs judiciously
Item 43: Return empty arrays or collections, not nulls
Item 44: Write doc comments for all exposed API elements

General Programming
Item 45: Minimize the scope of local variables
Item 46: Prefer for-each loops to traditional for loops
Item 47: Know and use the libraries
Item 48: Avoid float and double if exact answers are required
Item 49: Prefer primitive types to boxed primitives
Item 50: Avoid strings where other types are more appropriate
Item 51: Beware the performance of string concatenation
Item 52: Refer to objects by their interfaces
Item 53: Prefer interfaces to reflection
Item 54: Use native methods judiciously
Item 55: Optimize judiciously
Item 56: Adhere to generally accepted naming conventions

Exceptions
Item 57: Use exceptions only for exceptional conditions
Item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors
Item 59: Avoid unnecessary use of checked exceptions
Item 60: Favor the use of standard exceptions
Item 61: Throw exceptions appropriate to the abstraction
Item 62: Document all exceptions thrown by each method
Item 63: Include failure-capture information in detail messages
Item 64: Strive for failure atomicity
Item 65: Don’t ignore exceptions

Concurrency
Item 66: Synchronize access to shared mutable data
Item 67: Avoid excessive synchronization
Item 68: Prefer executors and tasks to threads
Item 69: Prefer concurrency utilities to wait and notify
Item 70: Document thread safety
Item 71: Use lazy initialization judiciously
Item 72: Don’t depend on the thread scheduler
Item 73: Avoid thread groups

Serialization
Item 74: Implement Serializable judiciously
Item 75: Consider using a custom serialized form
Item 76: Write readObject methods defensively
Item 77: For instance control, prefer enum types to readResolve
Item 78: Consider serialization proxies instead of serialized instances

Simulation in Bizagi - explained