"Developers are now the real decision makers in technology. Learning how to best negotiate with these New Kingmakers, therefore, could mean the difference between success and failure".
Really? Will the cloud change the power structure of IT? Or does this apply only to software business, not to business in general?
segunda-feira, 24 de fevereiro de 2014
sábado, 15 de fevereiro de 2014
No Methodologies
Why don’t software development methodologies work?
An experienced programmer - a "typical" programmer -, one who have used all methodologies and "techniques du jour" shows clearly that methodology is not the key to producing good software.
The text strongly suggests that the key to good software is... the programmer. As a craftsman. Which puts the last nail in the coffin of so-called Software Engineering.
Simple: Software is not engineering. It is related to Art, Craft and Mathematics.See Knuth The Art of Computer Programming.
" I’ve lived through waterfall/BDUF (big design up front), structured programming, top-down, bottom-up, modular design, components, agile, Scrum, extreme, TDD, OOP, rapid prototyping, RAD, and probably others I’ve forgotten about. I’m not convinced any of these things work."
"My own experience, validated by Cockburn’s thesis and Frederick Brooks in No Silver Bullet, is that software development projects succeed when the key people on the team share a common vision, what Brooks calls “conceptual integrity.” This doesn’t arise from any particular methodology, and can happen in the absence of anything resembling a process. I know the feeling working on a team where everyone clicks and things just get done. What I don’t understand is why I had that feeling a lot more in the bad old days of BDUF and business analysts than I do now."
"I think programmers should pay much more attention to listening to and working with their peers than to rituals and tools, and that we should be skeptical of too much process or methodologies that promise to magically make everyone more productive"
An experienced programmer - a "typical" programmer -, one who have used all methodologies and "techniques du jour" shows clearly that methodology is not the key to producing good software.
The text strongly suggests that the key to good software is... the programmer. As a craftsman. Which puts the last nail in the coffin of so-called Software Engineering.
Simple: Software is not engineering. It is related to Art, Craft and Mathematics.See Knuth The Art of Computer Programming.
" I’ve lived through waterfall/BDUF (big design up front), structured programming, top-down, bottom-up, modular design, components, agile, Scrum, extreme, TDD, OOP, rapid prototyping, RAD, and probably others I’ve forgotten about. I’m not convinced any of these things work."
"My own experience, validated by Cockburn’s thesis and Frederick Brooks in No Silver Bullet, is that software development projects succeed when the key people on the team share a common vision, what Brooks calls “conceptual integrity.” This doesn’t arise from any particular methodology, and can happen in the absence of anything resembling a process. I know the feeling working on a team where everyone clicks and things just get done. What I don’t understand is why I had that feeling a lot more in the bad old days of BDUF and business analysts than I do now."
"I think programmers should pay much more attention to listening to and working with their peers than to rituals and tools, and that we should be skeptical of too much process or methodologies that promise to magically make everyone more productive"
sábado, 8 de fevereiro de 2014
Software pronto não é software
Artigo Geraldo Coen 2011
E tese proposta em 2010: O Fim do Software, e como Recomeçar: "O objetivo deste trabalho é mostrar que se pode usar o conceito de máquina universal como modelo para o desenvolvimento de software."
Aplicação prática deste trabalho é um ambiente de desenvolvimento para software, comercial e outros, que é uma planilha cujas células são expressões LISP.
Assim, o ciclo clássico REPL é aplicado a uma planilha, o que é familiar aos usuários de planilha. A planilha se torna, usando expressões LISP, uma máquina universal. Além disso, execução em paralelo fica muito fácil, uma vez que os relacionamentos entre células indicarão as restrições ao processamento em paralelo. Finalmente, no caso particular de uma planilha com uma só célular leva ao sistema LISP (ou qualquer outra linguagem, ou EMACS, etc) atual.
E tese proposta em 2010: O Fim do Software, e como Recomeçar: "O objetivo deste trabalho é mostrar que se pode usar o conceito de máquina universal como modelo para o desenvolvimento de software."
Aplicação prática deste trabalho é um ambiente de desenvolvimento para software, comercial e outros, que é uma planilha cujas células são expressões LISP.
Assim, o ciclo clássico REPL é aplicado a uma planilha, o que é familiar aos usuários de planilha. A planilha se torna, usando expressões LISP, uma máquina universal. Além disso, execução em paralelo fica muito fácil, uma vez que os relacionamentos entre células indicarão as restrições ao processamento em paralelo. Finalmente, no caso particular de uma planilha com uma só célular leva ao sistema LISP (ou qualquer outra linguagem, ou EMACS, etc) atual.
Assinar:
Postagens (Atom)