Mostrando postagens com marcador Software engineering. Mostrar todas as postagens
Mostrando postagens com marcador Software engineering. Mostrar todas as postagens
sexta-feira, 2 de fevereiro de 2018
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, 19 de outubro de 2013
Things I will not bother with next time
Insight on software engineering and methodologies: they are great for standard projects. But standard projects are not creative software. And is there really a standar project?
"As for sound engineering principles in general, I think one important trait is to know when the established best-practices apply and when they do not.": Unlearning Software Engineering
"As for sound engineering principles in general, I think one important trait is to know when the established best-practices apply and when they do not.": Unlearning Software Engineering
domingo, 27 de janeiro de 2013
Software Engineering ≠ Computer Science
Software Engineering different from Computer Science, by Chuck Connel. Several ideas: methods, in engineering, are approximate, but physics formulae are exact. They are mathematics formulae. And software is mathematics. There are no approximations, so no engineering. This is a fundamental quality of sotware. There is no "usually" or "in general".
Author said "The line is the property "directly involves human activity". Software engineering has this property, while traditional computer science does not. The results from disciplines below the line might be used by people, but their results are not directly affected by people.": this is not so. If the algortihm is correct, the software is maintenable and safe.
Agree that "Software engineering will never be a rigorous discipline with proven results, because it involves human activity." Agree for the requirements, not the algorithm.
Also agree that "If some area of software engineering is solved rigorously, you can just redefine software engineering not to include that problem." So, a good practice is to use more good software.
And "We should stop trying to prove fundamental results in software engineering and accept that the significant advances in this domain will be general guidelines."
See also Is Software Engineering Engineering? by Peter J. Denning and Richard D. Riehle. (march 2009 | vol. 52 | no. 3 | communications of the acm) Comments: Software is the opposite of engineering. Problems has to be formulated in mathematical terms in order for the solution to be perfect. And abstraction - which is difficult - solves the complexity.
See also Software Developers' Views of End-Users and Project Success.
Author said "The line is the property "directly involves human activity". Software engineering has this property, while traditional computer science does not. The results from disciplines below the line might be used by people, but their results are not directly affected by people.": this is not so. If the algortihm is correct, the software is maintenable and safe.
Agree that "Software engineering will never be a rigorous discipline with proven results, because it involves human activity." Agree for the requirements, not the algorithm.
Also agree that "If some area of software engineering is solved rigorously, you can just redefine software engineering not to include that problem." So, a good practice is to use more good software.
And "We should stop trying to prove fundamental results in software engineering and accept that the significant advances in this domain will be general guidelines."
See also Is Software Engineering Engineering? by Peter J. Denning and Richard D. Riehle. (march 2009 | vol. 52 | no. 3 | communications of the acm) Comments: Software is the opposite of engineering. Problems has to be formulated in mathematical terms in order for the solution to be perfect. And abstraction - which is difficult - solves the complexity.
See also Software Developers' Views of End-Users and Project Success.
quinta-feira, 23 de junho de 2011
Software Engineering: An Idea Whose Time Has Come and Gone?
DeMarco Reflects on 40 Years of Software Engineering Evolution: "On the 40th anniversary of NATO's "Conference on Software Engineering," where the discipline of software engineering was first proposed, Tom DeMarco paused to reflect on the discipline's evolution, including his role in influencing its initial direction toward metrics. The author of the much-quoted "You can’t control what you can’t measure" now wonders whether this orientation has distracted us from the real point of computing: "The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business." His conclusion, under the title "Software Engineering: An Idea Whose Time Has Come and Gone?" [pdf] appeared in the July/August edition of IEEE Software magazine."
Chuck Connell, Software Engineering is not equal do Computer Science: "Software engineering will never be a rigorous discipline with proven results, because it involves human activity. "
sábado, 22 de janeiro de 2011
Software Engineering is the #1 Job in the United States in 2011
Java World, January 9
In its annual review of career opportunities, CareerCast recently ranked Software Engineering as the #1 job in the United States for 2010. This continues a recent trend, in which the software engineering, software development and programming professions have received high rankings in various career surveys. In the previous year's rankings, for example, Software Engineering was ranked as the #2 job. The article explores possible reasons why Software Engineering is enjoying new popularity and responds to reader comments about the specific roles and responsibilities of Software Engineering.
There are several reasons why Software Engineering moved to the #1 spot for 2011. The study identified the software engineering job market as widening in both scope and diversity, thanks primarily to cloud computing and mobile device development. The greater number and variety of positions leads to greater potential for an industry and reduces the competitiveness factor in finding new jobs. At the same time, the stress factor for Software Engineering careers declined, enabling an improved work-life balance.
The article and its methodology attracted a number of comments and vocal reader feedback. For example, readers debated the finer points of how a software engineer is different from a programmer or coder. They also debated the relative value of the various components of what makes a "good job" or "good career." Overall, software engineering is a solid choice of career when looking at the ratio of reward to effort. There are few careers with such a high level of compensation for a bachelor's degree, which is the typical educational level of software engineers though some have more and some have less formal secondary education.
(from ACM CareerNews, January 18, 2011)
In its annual review of career opportunities, CareerCast recently ranked Software Engineering as the #1 job in the United States for 2010. This continues a recent trend, in which the software engineering, software development and programming professions have received high rankings in various career surveys. In the previous year's rankings, for example, Software Engineering was ranked as the #2 job. The article explores possible reasons why Software Engineering is enjoying new popularity and responds to reader comments about the specific roles and responsibilities of Software Engineering.
There are several reasons why Software Engineering moved to the #1 spot for 2011. The study identified the software engineering job market as widening in both scope and diversity, thanks primarily to cloud computing and mobile device development. The greater number and variety of positions leads to greater potential for an industry and reduces the competitiveness factor in finding new jobs. At the same time, the stress factor for Software Engineering careers declined, enabling an improved work-life balance.
The article and its methodology attracted a number of comments and vocal reader feedback. For example, readers debated the finer points of how a software engineer is different from a programmer or coder. They also debated the relative value of the various components of what makes a "good job" or "good career." Overall, software engineering is a solid choice of career when looking at the ratio of reward to effort. There are few careers with such a high level of compensation for a bachelor's degree, which is the typical educational level of software engineers though some have more and some have less formal secondary education.
(from ACM CareerNews, January 18, 2011)
Assinar:
Postagens (Atom)