The Least Sophisticated Software Process

1. Discuss the software that needs to be written.
2. Write some code.
3. Test the code to identify the defects. 
4. Debug to find root causes of defects. 
5. Fix the defects.
6. If the project isn't done yet, return to step 1.

Business Rules Engine

Behavior is the most important thing about software

Behavior is the most important thing about software. It is what users depend on. Users like it when we add behavior (provided it is what they really wanted), but if we change or remove behavior they depend on (introduce bugs), they stop trusting us.

Legacy code is simply code without tests

Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t mat- ter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.

Refactor x Rewrite

Developers and architects like to build things

Reasons for the code base getting worse over time,

• More and more features. It leads to increased complexity.
• Shortcuts and hacks to support “We need this fancy search till August. Period!” features
• Developers rotation. New developers don’t know all the fundamental decisions and ideas behind the architecture. Knowledge gets lost with transition inevitably.
• Development team growth. More people - less communication. Less communication - bad decisions.

Simple business process model with role information

Internal structure of value chain

Message-oriented Middleware

Evolution of Enterprise Systems Architectures

Estimate uncertainty

An Interactive Life Cycle

Iterative-incremental Development and the Rational Unified Process

Changing focus across the RUP lifecycle

Managing requirements

Example elicitation and analysis methods

5 coisas que os Estoicos podem te ensinar sobre desenvolvimento de software

1. Vire o obstáculo de cabeça para baixo

“Escolha não ser prejudicado e você não se sentirá prejudicado. Não se sinta prejudicado e você não o será” – Marco Aurélio

Os estoicos tinham um exercício chamado “Virando o obstáculo de cabeça para baixo”, no qual eles simplesmente tentavam ver o problema de um ângulo diferente, que é benéfico para você. Por exemplo: back-end não é seu negócio, mas sua empresa precisa de alguém que desenvolva em Java. Você pode enxergar essa situação como um obstáculo ou como uma oportunidade para aprender uma coisa nova.

2. Você tem muito tempo

“Não é que nós temos pouco tempo para viver, é que nós desperdiçamos um monte dele. A vida é longa o suficiente, e uma quantidade generosa é dada a nós para atingirmos as maiores conquistas se investirmos bem. Mas quando desperdiçamos tempo em luxo desnecessário e em atividades que não são boas, nós somos forçados pela limitação da morte a entender que tudo passou antes que nós percebêssemos que estava passando. Então é isso: não temos uma vida curta, nós a tornamos curta, e nós não somos mal suportados, nós é que desperdiçamos tempo… A vida é longa se você sabe como usá-la” – Sêneca

Eu concordo que às vezes seu chefe pode criar deadlines difíceis. Mas na maior parte do tempo, os desenvolvedores de software reclamam sem entender que eles não estão usando o seu tempo bem o suficiente. Fatores externos, como deadlines, não são sua culpa. Mas ser improdutivo é totalmente culpa sua.

3. Sem falha não há crescimento

“O que aconteceu com você o impediu de: agir com justiça, generosidade, autocontrole, sanidade, prudência, honestidade, humildade, simplicidade e todas as outras qualidades que permitem a natureza de uma pessoa para se satisfazer? Então, lembre deste princípio quando algo ameaçar te causar dor: a coisa em si não é de todo ruim, passar por ela e sobreviver é a grande sorte” – Marco Aurélio

Projetos podem dar errado, seu código pode levar a uma perda enorme de dinheiro ou você pode ser demitido, mas você tem que saber que existe vida depois do fracasso. E não é só isso, mas com o pensamento certo, quando você se recuperar de cada fracasso você estará mais forte e pronto para brilhar de novo. Lembre-se de que se você não está fracassando, você não está crescendo.

4. Não apenas leia. Pratique.

“Não diga apenas que você leu livros, mostre que por meio deles você aprendeu a pensar melhor e a ser uma pessoa mais reflexiva e sensata. Livros são os halteres da mente. Eles são muito úteis, mas seria um erro supor que alguém progrediu apenas por internalizar seu conteúdo”. – Epiteto

Ler é ótimo, especialmente para aprender por meio dos erros de outras pessoas. Mas ler, apenas, sem aplicar o que você leu, é um completo desperdício de tempo. Eu tenho visto muitos desenvolvedores lendo posts em blog, livros e outros tipos de conteúdo mas não aplicando quase nada disso. O propósito da educação é internalizar conhecimento, mas definitivamente é necessário tomar alguma atitude a partir disso.

5. Aprenda a lidar com as pessoas

“Comece todos os dias dizendo para si mesmo: hoje eu devo encontrar interferência, ingratidão, insolência, deslealdade, má vontade e egoísmo – tudo isso por causa da ignorância das pessoas em saber o que é bom ou ruim” – Marco Aurélio

A parte mais difícil do desenvolvimento de software com certeza não são questões técnicas, mas como lidar com as pessoas. Os estoicos lidam com esse tipo de adversidade usando uma prática chamada de “premeditar as expectativas”: todas as manhãs você deve acordar, sentar silenciosamente e ser muito pessimista. Dessa forma você já estará mentalmente preparado para as adversidades que te acontecerem e eles não te afetarão tanto.

Em resumo, o estoicismo nos ensina a não lutar com a natureza das coisas. Ao invés de investirmos energias em coisas que não conseguimos mais mudar ou de tentarmos evitar o inevitável podemos nos concentrar em ter a mente tranquila para a transposição dos obstáculos. A natureza do mundo de desenvolvimento de produtos digitais pode ser muito severa para os olhos de uns, porém, com o treinamento mental e preparação comportamental podemos nos tornar mais fortes para as adversidades.

Fonte: http://blog.concretesolutions.com.br/2015/11/estoicos-e-software/

Agile Methodology - Roger Pressman

Domain Driven Design

The ultimate purpose of software is to serve users. But first it has to serve developers. This is especially true in a process that emphasizes refactoring. As the program evolves, developers will rearrange and rewrite every part. They will integrate the domain objects into the application and with new domain objects. Even years later, maintenance programmers will be changing and extending the code. People have to work with this stuff.