The document summarizes a working session on software engineering myths held on October 4, 2007 in Paris. The session included discussions of common myths in areas such as complexity, bugs, clones, aspect-oriented programming, and project management. Participants shared and debated myths in small group discussions. Some examples of myths discussed include the ideas that complexity leads to more bugs, clones are always bad, and aspect-oriented programs are inherently easier to maintain. The session aimed to evaluate whether such perceptions are truly myths or if aspects of them have been found to hold true in various studies.
In the movie, RoboCop is given three primary directives: "Serve the public trust, Protect the innocent, and Uphold the law". We built our own RoboCop in order to bring law and order to our CI/CD pipeline. DevOps practices are all about enabling fast and frequent delivery of new software. In order to keep pace in a DevOps culture, application security must be reliably integrated into the CI/CD pipeline.
In the movie, RoboCop is given three primary directives: "Serve the public trust, Protect the innocent, and Uphold the law". We built our own RoboCop in order to bring law and order to our CI/CD pipeline. DevOps practices are all about enabling fast and frequent delivery of new software. In order to keep pace in a DevOps culture, application security must be reliably integrated into the CI/CD pipeline.
6 Most Common Threat Modeling MisconceptionsCigital
There are some very common misconceptions that can cause firms to lose their grip around the threat modeling process. This presentation shines a bright light onto the essentials and helps to get your bearings straight with all things related to threat modeling.
We know that software is important to our lives. Today, software was applied to diverse applications, but there are still many problems. Software Engineering was established to find solutions to various problems. About Software Development I expect that this presentation will be the one that keeps pushing, as a starting point or inspires you to interested in learning further about software engineering.
In the world of DevSecOps as you may predict we have three teams working together. Development, the Security team and Operations.
The “Sec” of DevSecOps introduces changes into the following:
• Engineering
• Operations
• Data Science
• Compliance
According to my previous slide share, Introduction to software engineering, http://www.slideshare.net/ssuser45a683/introduction-to-software-engineering-48462625. I would like to expand further in part of software testing.
Software testing is vital, no less than software development. It can be said that software testing should be the same level as software development.
The content of this slide will discuss the meaning of software testing. The importance of software and concepts of software testing.
Getting to Know Security and Devs: Keys to Successful DevSecOpsFranklin Mosley
In the past, security was seen as function of the ‘security’ organization. With DevOps, we aim to break down these silos, and make security a shared responsibility. What do Security and Development teams need know about each other to work together more effectively?
Much attention has been given to the need for increased automation in security, given the sheer volume of attackers and attacks, the overload of information security pros must wrangle, and the continued high demand for security expertise. But can automation solve all of security’s most serious problems? If not, why not? Will there always be a need for human involvement?
These slides were used in a live webcast featuring, 451 Research Information Security Research Director Scott Crawford and Cigital Managing Principal Nabil Hannan. You can watch this and other webcasts by visiting https://www.cigital.com/resources/.
Software Engineering - Ch1 introduction
This material is based on chapter 1 of “Software Engineering (l0th Edition)” by Ian Sommerville. Addison Wesley, 2015, ISBN-10: 0137035152.
https://iansommerville.com/software-engineering-book/
Using security to drive chaos engineering - April 2018Dinis Cruz
Presentation I delivered at ISSA UK "Application Security - London Chapter Meeting" https://www.eventbrite.co.uk/e/application-security-london-chapter-meeting-tickets-42284085839
5 Things Every CISO Needs To Know About Open Source Security - A WhiteSource ...WhiteSource
The best approaches and practices that security teams should implement in order to enable their developers to harness the power of open source without slowing them down or compromising on security.
Winning open source vulnerabilities without loosing your deveopers - Azure De...WhiteSource
Tsaela Pinto, Director of Knowledge R&D at WhiteSource, spoke at the Azure DevOps meetup in Tel Aviv about how develpers should part in maintaining open source security
Bringing Security Testing to Development: How to Enable Developers to Act as ...Achim D. Brucker
Security testing is an important part of any security development life-cycle (SDLC) and, thus, should be a part of any software development life-cycle.
We will present SAP's Security Testing Strategy that enables developers to find security vulnerabilities early by applying a variety of different security testing methods and tools. We explain the motivation behind it, how we enable global development teams to implement the strategy, across different SDLCs and report on our experiences.
Slides from my DevOpsExpo London talk "From oops to NoOps".
They tell you in these conferences that DevOps is not about tools, but about culture. And they are partially right. I am going to tell you that it’s not only about culture or tools but also abstractions.
It is a lot about how you see software and its value. About our mental model of what software is: how it runs, evolves, and interacts with the other facets of an enterprise.
We used to view software as code. As a state of code. Now we think about software as change, as a flow. A dynamic system where people, machines, and processes interact continuously.
At Platform.sh we spend a bunch of time asking ourselves not “How do you build?” - or even “How do you build consistently?” - but rather “What does it mean to consistently build in a world where change is good?” A world that lets you push security fixes into production as soon as they’re available because you don’t want to be an Equifax but you do want stability.
In this presentation, I will go over what we think software is and why having the right ideas about software will help you get your culture right and your tooling aligned, as well as gain in productivity, and general happiness and well-being.
6 Most Common Threat Modeling MisconceptionsCigital
There are some very common misconceptions that can cause firms to lose their grip around the threat modeling process. This presentation shines a bright light onto the essentials and helps to get your bearings straight with all things related to threat modeling.
We know that software is important to our lives. Today, software was applied to diverse applications, but there are still many problems. Software Engineering was established to find solutions to various problems. About Software Development I expect that this presentation will be the one that keeps pushing, as a starting point or inspires you to interested in learning further about software engineering.
In the world of DevSecOps as you may predict we have three teams working together. Development, the Security team and Operations.
The “Sec” of DevSecOps introduces changes into the following:
• Engineering
• Operations
• Data Science
• Compliance
According to my previous slide share, Introduction to software engineering, http://www.slideshare.net/ssuser45a683/introduction-to-software-engineering-48462625. I would like to expand further in part of software testing.
Software testing is vital, no less than software development. It can be said that software testing should be the same level as software development.
The content of this slide will discuss the meaning of software testing. The importance of software and concepts of software testing.
Getting to Know Security and Devs: Keys to Successful DevSecOpsFranklin Mosley
In the past, security was seen as function of the ‘security’ organization. With DevOps, we aim to break down these silos, and make security a shared responsibility. What do Security and Development teams need know about each other to work together more effectively?
Much attention has been given to the need for increased automation in security, given the sheer volume of attackers and attacks, the overload of information security pros must wrangle, and the continued high demand for security expertise. But can automation solve all of security’s most serious problems? If not, why not? Will there always be a need for human involvement?
These slides were used in a live webcast featuring, 451 Research Information Security Research Director Scott Crawford and Cigital Managing Principal Nabil Hannan. You can watch this and other webcasts by visiting https://www.cigital.com/resources/.
Software Engineering - Ch1 introduction
This material is based on chapter 1 of “Software Engineering (l0th Edition)” by Ian Sommerville. Addison Wesley, 2015, ISBN-10: 0137035152.
https://iansommerville.com/software-engineering-book/
Using security to drive chaos engineering - April 2018Dinis Cruz
Presentation I delivered at ISSA UK "Application Security - London Chapter Meeting" https://www.eventbrite.co.uk/e/application-security-london-chapter-meeting-tickets-42284085839
5 Things Every CISO Needs To Know About Open Source Security - A WhiteSource ...WhiteSource
The best approaches and practices that security teams should implement in order to enable their developers to harness the power of open source without slowing them down or compromising on security.
Winning open source vulnerabilities without loosing your deveopers - Azure De...WhiteSource
Tsaela Pinto, Director of Knowledge R&D at WhiteSource, spoke at the Azure DevOps meetup in Tel Aviv about how develpers should part in maintaining open source security
Bringing Security Testing to Development: How to Enable Developers to Act as ...Achim D. Brucker
Security testing is an important part of any security development life-cycle (SDLC) and, thus, should be a part of any software development life-cycle.
We will present SAP's Security Testing Strategy that enables developers to find security vulnerabilities early by applying a variety of different security testing methods and tools. We explain the motivation behind it, how we enable global development teams to implement the strategy, across different SDLCs and report on our experiences.
Slides from my DevOpsExpo London talk "From oops to NoOps".
They tell you in these conferences that DevOps is not about tools, but about culture. And they are partially right. I am going to tell you that it’s not only about culture or tools but also abstractions.
It is a lot about how you see software and its value. About our mental model of what software is: how it runs, evolves, and interacts with the other facets of an enterprise.
We used to view software as code. As a state of code. Now we think about software as change, as a flow. A dynamic system where people, machines, and processes interact continuously.
At Platform.sh we spend a bunch of time asking ourselves not “How do you build?” - or even “How do you build consistently?” - but rather “What does it mean to consistently build in a world where change is good?” A world that lets you push security fixes into production as soon as they’re available because you don’t want to be an Equifax but you do want stability.
In this presentation, I will go over what we think software is and why having the right ideas about software will help you get your culture right and your tooling aligned, as well as gain in productivity, and general happiness and well-being.
Continuous Automated Testing - Cast conference workshop august 2014Noah Sussman
CAST 2014 New York: The Art and Science of Testing
The Association for Software Testing www.associationforsoftwaretesting.org
COURSE DESCRIPTION
Automated tools provide test professionals with the capability to make relevant observations even in the fastest-paced environments. Automated testing is also a powerful tool for improving communication between software engineers. This is important because good communication is a prerequisite for growing a great software engineering organization.
This workshop will explore the continuous testing of software systems. Special focus will be given to the situation where the engineering team is deploying code to production so frequently that it is not possible to perform deep regression testing before each release.
People who participate in this course will learn pragmatic automated testing strategies like:
* Data analysis on the command line with find, grep and wc.
* Network analysis with Chrome Inspector, Charles and netcat.
* Using code churn to predict hotspots where bugs may occur.
* Putting stack traces in context with automated SCM blame emails.
* Using statsd to instrument a whole application.
* Testing in production.
* Monitoring-as-testing.
Technical level: participants should have some familiarity with the command line and with editing code using a text editor or IDE. Familiarity with Git, SVN or another version control system is helpful but not required. Likewise some knowledge of Web servers is helpful but not required. It is desirable for participants to bring laptops.
BIO
From 2010 to 2012 Noah was a Test Architect at Etsy. He helped build Etsy's continuous integration system, and has helped countless other engineers develop successful automated testing strategies.These days Noah is an independent consultant in New York. He is passionate about helping engineers understand and use automated tools as they work to scale their applications more effectively.
Konstantin Knizhnik: static analysis, a view from asidePVS-Studio
The article is an interview with Konstantin Knizhnik taken by Andrey Karpov, "Program Verification Systems" company's worker. In this interview the issues of static code analysis, relevance of solutions made in this sphere and prospects of using static analysis while developing applications are discussed.
Software Ecosystems as Networks - Advances on the FASTEN project, Paolo Boldi...Fasten Project
FASTEN was presented in the Devroom on Dependency Management at FOSDEM 2021. Presentation Abstract: The goal of the EU project FASTEN is being able to perform a more sophisticated analysis of security-vulnerability propagation, licensing compliance, and dependency risk profiles (among others) by relying on the call-level dependency network of the whole software ecosystem. We outline the purpose and structure of the project, and present some preliminary results.
Enhancing Developer Productivity with Code ForensicsTechWell
Imagine an engineering system that could evaluate developer performance, recognize rushed check-ins, and use that data to speed up development. “Congratulations Jane. You know this code well. No check-in test gate for you.” Anthony Voellm shares how behavioral analysis and developer assessments can be applied to improve productivity. This approach was motivated by today's test systems, tools, and processes that are all designed around the premise that “all developers are created equal.” Studies have shown developer error rates can vary widely and have a number of root causes—the mindset of the developer at the time the code was written, experience level, amount of code in a check-in, complexity of the code, and much more. With Digital Code Forensics, a set of metrics that can evaluate developers, Anthony demonstrates how even modest applications of this approach can speed up development. Discover and use the cutting edge of engineering productivity.
Two years ago at Devoxx UK we talked about DevOps, what it was, why it was important and how to get started. Boy, was it scary. Now we’re wiser. More battle-scarred. The large scale of the challenge for application writers exploiting cloud and DevOps is clearer, but so is the path forward. Understanding the DevOps approach is important, but equally you must understand specific deployment technologies, security issues, operational reliability, and how to drive organisational transformation. Whether creating simple applications or sophisticated microservice architectures many of the challenges are the same. Join us to learn how you can apply this within your team and company.
No Silver Bullet Essence and Accidents ofSoftware Engineeri.docxcurwenmichaela
No Silver Bullet: Essence and Accidents of
Software Engineering
by Frederick P. Brooks, Jr.
Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because
they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can
magically lay them to rest.
The familiar software project, at least as seen by the nontechnical manager, has something of this
character; it is usually innocent and straightforward, but is capable of becoming a monster of missed
schedules, blown budgets, and flawed products. So we hear desperate cries for a silver bullet--something
to make software costs drop as rapidly as computer hardware costs do.
But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single
development, in either technology or in management technique, that by itself promises even one order-
of-magnitude improvement in productivity, in reliability, in simplicity. In this article, I shall try to show
why, by examining both the nature of the software problem and the properties of the bullets proposed.
Skepticism is not pessimism, however. Although we see no startling breakthroughs--and indeed, I
believe such to be inconsistent with the nature of software--many encouraging innovations are under
way. A disciplined, consistent effort to develop, propagate, and exploit these innovations should indeed
yield an order-of-magnitude improvement. There is no royal road, but there is a road.
The first step toward the management of disease was replacement of demon theories and humours
theories by the germ theory. That very step, the beginning of hope, in itself dashed all hopes of magical
solutions. It told workers that progress would be made stepwise, at great effort, and that a persistent,
unremitting care would have to be paid to a discipline of cleanliness. So it is with software engineering
today.
Does It Have to Be Hard?--Essential Difficulties
Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there
will be any--no inventions that will do for software productivity, reliability, and simplicity what
electronics, transistors, and large-scale integration did for computer hardware. We cannot expect ever to
see twofold gains every two years.
First, one must observe that the anomaly is not that software progress is so slow, but that computer
hardware progress is so fast. No other technology since civilization began has seen six orders of
magnitude in performance price gain in 30 years. In no other technology can one choose to take the gain
in either improved performance or in reduced costs. These gains flow from the transformation of
computer manufacture from an assembly industry into a process industry.
Second, to see what rate of progress one can expect in software technology, let us examine the
difficulties of that technology. Following Aristotle, I divide them into essence, the difficulties inhe ...
At some point, the code you write today will be deleted and replaced with something new. This talk will discuss the life cycle of a large code base, and how to manage it over time to accommodate rewrites, giving examples from a major rewrite of the Firefox build and release pipeline over the last two years. You'll learn how to replace components of a running distributed system while keeping it operational, the proverbial replacing the wing of an airplane in flight.
Programmers love science! At least, so they say. Because when it comes to the ‘science’ of developing code, the most used tool is brutal debate. Vim versus emacs, static versus dynamic typing, Java versus C#, this can go on for hours at end. In this session, software engineering professor Felienne Hermans will present the latest research in software engineering that tries to understand and explain what programming methods, languages and tools are best suited for different types of development.
Similar to Got Myth? Myths in Software Engineering (20)
A preview of the MSR 2013 conference, May 18-19, 2013, in San Francisco, CA. REGISTER NOW! Early registration discounts until April 14. http://msrconf.org
Empirical Software Engineering at Microsoft ResearchThomas Zimmermann
An invited talk that I gave in Tokyo. Very special thanks to Shuji Morisaki who was my translator during the session. Many thanks to Chris Bird, Nachi Nagappan, Rahul Premraj, and Sascha Just who provided slides for this talk.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Generating a custom Ruby SDK for your web service or Rails API using Smithyg2nightmarescribd
Have you ever wanted a Ruby client API to communicate with your web service? Smithy is a protocol-agnostic language for defining services and SDKs. Smithy Ruby is an implementation of Smithy that generates a Ruby SDK using a Smithy model. In this talk, we will explore Smithy and Smithy Ruby to learn how to generate custom feature-rich SDKs that can communicate with any web service, such as a Rails JSON API.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
8. Myths in SE?
Bugs reside in complex code
Aspect-oriented programs
are easy to maintain
Clones are evil!
9. Myths in SE?
Bugs reside in complex code
Aspect-oriented programs
are easy to maintain
Mythical man month
Clones are evil!
10.
11. Thanks!
Winifred Menezes
Israel Herraiz
pmerson
Gregor Kiczales
Chanchal Kumar Roy
Farooq Iqbal Huzefa Kagdi
12. Schedule
14:00-14:20 Intro & Wiki News
14:20-15:30 The Clone War Begins
15:30-16:00 Break
16:00-16:45 Bugs! Bugs! Bugs!
16:45-17:15 Top 100 Myths
17:15-17:30 Future of Myths in SE
15. Bugs reside
in complex code.
In the quest for metrics that predict bugs, many tools report
various code complexity metrics; however, recent studies show
that most complexity metrics correlate with just LOC. Is it
really complexity that makes programs fail?
16. Bugs reside in complex code
■ In an 80s study on a ~90KLOC program for satellite
planning, Basili and Perricone noted that
– The larger modules (size in LOC) were less error prone
– Error-prone modules did not have higher (cyclomatic) complexity
than error-free modules. In fact, the defect rate of modules
decreased with the increase in size and complexity
– These results were quite surprising. So, bugs reside in complex: a
myth or not a conclusive fact yet that needs further establishment?
■ In 2007 Herraiz and colleagues showed that
– LOC and SLOC are highly correlated with classical complexity
metrics for the case of the C programming language
– The study was performed on a sample of 700,000 files, obtained
from all the software packages included in FreeBSD
17. Bugs reside in complex code
■ I guess it depends on what is meant by complexity - many
paths through the code, many jumps backward and
forward, many loops. Clearly the more LOC - the more
possibility there is for any or all of the above
■ I have done research on software defect models. I did a
survey and most software people think that complexity is a
good predictor of defects.
– But some analysis done with defect data of various projects
revealed to me that complexity (cyclomatic complexity) is not
correlated with defects. I think software defects depend upon
multiple factors out of which one can be 'complexity'.
18. Clones are evil!
For a long time code cloning was considered harmful;
however, recent studies show that cloning might even be
beneficial and desirable...
19. Clones are evil!
■ Cordy reports that removing clones
increases risk for large systems
■ Kim et al. examine the evolution of clones
and conclude that clone refactoring would
not help many of the long lived clones
■ Kapser and Godfrey describe several
patterns of clonning and discuss their
benefits for the long term evolution of
software systems
20. Clones are evil!
■ Aversano et al. study co-change analysis and show
that most of the cloned code is consistently
maintained, particularly while bug fixing of cloned
fragments. Their study indirectly shows that clones
may not be harmful to software maintenance
■ A prototype tool, CloneTracker, has been developed
by Lozano et al. to evaluate the harmfulness of
cloning. Although their case study intends to show
that clones are harmful, they were unsure of the
results
21. Clones are evil!
■ Monden et al. conducted an experiment for evaluating the
relation between clones and software quality attributes,
namely reliability and maintainability with industrial
systems. Their study shows that
– modules/files with code clones are on average 1.7 times more
reliable than files/modules without code clones
– However, modules/files with larger clones are less reliable than
others
■ In the case of maintainability quality attribute, their results
also support the usual hypothesis that clones have a bad
impact on software maintenance
■ Koschke has a survery of state of research in cloning
22. AOP programs are
easy to maintain.
Aspect-oriented programming seems to be a story of successes;
however, after ten years of active research (including its own
conference), it is not clear whether aspect-oriented programs
are any easier to maintain than traditional programs.
23. Aspect-oriented programs are
easy to maintain
■ No rational AOP proponent would stand by this claim
■ For one thing, a badly written AOP program is not easy to
maintain. Moreover, a program that really needs AOP is
an inherently more complex thing than a program that
really doesn’t need AOP — so there’s an apples vs.
oranges error to be careful for there
■ In the end, the only reasonable claim one could make
about AOP is that
– When a system’s functionality inherently has crosscutting concerns,
proper use of AOP leads to an implementation that is easier to
maintain than the implementation one would get without AOP
■ Slides for AOP myths and realities
24. The mythical
man month
Many software project managers still believe that men and
months are interchangeable commodities in software project
schedules.
25. Mythical Man Month
■ Project managers use the number of men and months as
interchangeable units for measuring the project effort.
■ “The number of men and months are interchangeable
measures in software projects” is a myth, Brooks 1975
■ McConnell argues that Brooks' Law is less pervasive than
it appears
■ Today
– Many managers still ignore the myth and add staff to software
projects running behind schedule.
– Coordination issues amplified with global software development.
Geographically distributed teams suffer with the lack of face-to-face
communication
26. Clones
■ What is a clone?
– Task oriented definition of a clone (can I refractor it)
– Intent matters (you meant it)
– Find problematic code patterns instead
■ Effect of clones in the long term:
– Refactoring is challenging but we provide tool support.
• Should we provide clone support
– Awareness is very important
■ How can we show that clones are good/bad?
– What type of studies are needed
• Scale/Industry vs. open source
■ What are bad clones?
– Any patterns of bad clones
27. Clones
■ Where should research go?
–New clone detection tools…
–Study the long term effects of clones
–Clone maintenance tools
■ How can we integrate clones into practice?
–Clones as a project management/release tool
–Clones as a way of coding (the new reuse!)
28. Clones
■ How can we show that clones are good/bad?
– What type of studies are needed
• Scale/Industry vs. open source
■ What are bad clones?
– Any patterns of bad clones
■ Where should research go?
– New clone detection tools
– Study the long term effects of clones
– Clone maintenance tools
■ How can we integrate clones into practice?
– Clones as a project management/release tool
– Clones as a way of coding (the new reuse!)
29. Bugs! Bugs! Bugs!
■ Watch out for confounding factors. It’s easy to be tricked.
■ History gives mostly correlations, rarely causation.
■ Are we using the wrong metrics?
– OO complexity is rarely captured
■ Certain kinds of bugs matter more.
■ Different models for different kind of bugs?
■ Bugs are some form of disease.
■ Where should research go?
– Better complexity metrics
– More (controlled) experiments
– Insure software against bugs (new business idea?)
31. Software complexity/maintenance cost can be calculated by
1.
measuring structural complexity
2. AOP promotes modularity
3. All new requirements can be implemented in an existing
codebase
4. Overtime in necessary and useful
5. Cutting QA will save us money
6. Open source is better quality than proprietary software
7. Linux will become un-maintainable because of high internal
coupling
8. Service orientation will lead to better (more maintainable)
systems
9. Open source applications are mainly developed by people
working in their free time on a voluntary basis and without
being paid for that
10. Aspects != cross-cutting concerns
11. Open source software development process is different from
industrial projects
32. Software testing is tedious but not hard (Not worth teaching in
12.
universities)
13. Linux is a representative open source project
14. Requirements are not useful in open source projects
15. Software visualization is helpful
16. C++ is faster than Java
17. UIs can be separated from their application
18. Design patterns make better code
19. Quality is free
20. God classes are a problem
21. Software maintenance (is software really “maintained”)
22. OO systems are easier to maintain than procedural
23. Gotos are harmful
24. Features added to Java are novel and not invented in the 70s.
25. Good software can only be built with good requirements
26. Good tools make good programmers
33. Good software cannot be built with a weakly typed language
27.
(like pythons)
28. Complexity of code will soon become unmanageable
29. Cobol is dead
30. It is not possible for a query language to be seriously logical
and seriously object oriented at the same time
31. XML will solve world hunger problems!
32. Legacy=bad
33. Macs are better than PCs
34. Vote BUSTED
or CONFIRMED
(The following slides report what was voted
by the majority of MythSE participants.)