Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What are some of the best programming/hacking conventions or conferences held yearly?
What are their names?
Where are they located?
What is a highlight about this conference/convention?
Programming/Hacking Conventions and Conferences Around The World
There are many conferences and conventions that are geared toward the programmer/hacker. Collaboration and sharing is one of the most important aspects of computer science, so here is a list of these incredible (or not-so-incredible) events that are held throughout the year (please contribute - this is a community wiki post):
- Game Developers Conference (GDC) - San Francisco, CA
The GDC attracts over 23,000 attendees, and is the primary forum where programmers, artists, producers, game designers, audio professionals, business decision-makers and others involved in the development of interactive games gather to exchange ideas and shape the future of the industry.
- DefCon - Las Vegas, NV
DEF CON (also written as DEFCON or Defcon) is one of the world's largest annual hacker conventions, held every year in Las Vegas, Nevada. The first DEF CON took place in June 1993.
Many of the attendees at DEF CON include computer security professionals, journalists, lawyers, federal government employees, security researchers, and hackers with a general interest in software, computer architecture, phone phreaking, hardware modification, and anything else that can be "hacked."
- Black Hat - Las Vegas, NV
The Black Hat Briefings are a series of highly technical information security conferences that bring together thought leaders from all facets of the infosec world - from the corporate and government sectors to academic and even underground researchers.
- ICFP - Boston, MA
ICFP (International Conference on Functional Programming) is an annual programming language conference. It is sponsored by the Association for Computing Machinery (ACM) under the aegis of the ACM Special Interest Group on Programming Languages (SIGPLAN), in association with Working Group 2.8 of the International Federation of Information Processing (IFIP). ICFP combined two former biennial conferences: Functional Programming and Computer Architecture (FPCA) and Lisp and Functional Programming (LFP)
- HPCS - Ottowa, ON, Canada
The High Performance Computing Symposium (HPCS) is Canada’s foremost supercomputing conference – a multidisciplinary conference where computational researchers from all disciplines in industry and academia, computer scientists, and vendors exchange new tools, techniques and interesting results in and for HPC computational research.
- MUSEPAT - Saint Petersburg, Russia
MUSEPAT is a forum for researchers and practitioners that face the multicore and distributed software challenge, addressing the full software development life-cycle of concurrent systems — software specification and design, programing models and techniques, testing, analysis, and debugging.
- ISPA - Melbourne, Australia
The objective of ISPA-13 is to provide a forum for scientists and engineers in academia and industry to exchange and discuss their experiences, new ideas, research results, and applications about all aspects of parallel and distributed computing and networking.
Related
According to Wikipedia Human Computer Interaction involves the study, planning, and design of the interaction between people (users) and computers.
Interaction Design is the practice of:
understanding users’ needs and goals
designing tools for users to achieve those goals
envisioning all states and transitions of the system
considering limitations of the user’s environment and technology
So what is the difference between studying Master in Human Computer Interaction vs Master in Interaction Design? I think interaction design has a broader scope and includes Human computer interaction as well. which one is more practical?
Human Computer Interaction (HCI) is a subset of Interaction Design. You could be forgiven for thinking that interaction design is rebranding of HCI.
Interaction design can be placed on a continuum which begins with the earliest tools, passes through the industrial revolution and stretches out into Weiser’s utopian predictions. In the early 1900’s Frederick Taylor employed current technologies, photography, moving pictures and statistical analysis to improve work practises. Engineering psychology was born and the terms ‘human factors’, ‘ergonomics’ entered into common lexicon. The explosion of information, brought about by what Grudin (2012:5) refers to as: “technologies and practices for compressing, distributing, and organizing information bloomed…were important inventions that influenced the management of information and organizations in the early 20th century”
The earliest computers, where incredibly expensive and where only accessed by specialists, Grudin (2012:7) reports that: “ENIAC, arguably the first general-purpose computer, was…eight to ten feet high, occupied about 1800 square feet, and consumed as much energy as a small town.” While some notable researchers such as Grace Hopper where concerned with the area of ‘programmer-computer interaction’ (a phrase coined by Grace Hopper), the affordability of these massive machines and their relative scarcity would be the single biggest stumbling block the evolution of usability and theories thereof.
Ivan Sutherland’s PhD thesis “Sketchpad: A man-machine graphical communication system” was groundbreaking rethink of the interface between operators and machines. Blackwell & Rodden write in the introduction (2003: 4) that while Sutherland’s demo could only run on one modified TX-2 in laboratory, it was: “one of the first graphical user interfaces. It exploited the light-pen, predecessor of the mouse, allowing the user to point at and interact with objects displayed on the screen.”
Sutherland’s ideas had a major impact on the work on Xerox’s Star’s designers, they used his idea of ‘icons’, a ‘GUI’ (Graphic User Interface), pointer control (in their case a mouse). Johnson et al (1989:11) reports that his team:
“assumed that the target users were interested in getting their work done and not at all interested in computers. Therefore, an important design goal was to make the ‘computer’ as invisible to users as possible…Another important assumption was that Star’s users would he casual, occasional users rather than people who spent most of their time at the machine. This assumption led to the goal of having Star be easy to learn and remember.’
The Star was not a commercial success, but it’s innovations ushered in a new era of ‘personal computing’ - this led to a boon in the area of research and the emergence of Human Computer Interaction (HCI), Grudin (2012:19) reports: “As personal computing spread, experimental methods were applied to study other contexts involving discretionary use. Studies of programming gradually disappeared from HCI conferences.”
Alan Cooper, an early Interaction Design practitioner in interview with Patton (2008:16) reports:
“I began experimenting with this whole new idea that it’s not about computer operators running a batch process, but about people sitting in front of the software and interacting directly.…it was really the microcomputers that drove that into my head.”
The evolution of Interaction design, notes Cooper, was in part driven by the need to specialise, he tells Patton (2008:17):
“I found myself in kind of a bind. I was going to have to either become part of a larger organization or let go of the implementation part of what I did.”
Industry practitioners realised that this interaction between human and computers, needed to develop a methodology. Alan Cooper (2008:17) relates:
“it would be much more valuable and interesting if I could figure out some objective methodology that I was going through. That would give me some leverage, and it would be good for the world, good for the industry.”
Bill Verplank, who worked on the Xerox Star, along with Bill Moggeridge first coined the phrase ‘interaction design’ (we should probably be thankful that Verplank convinced Moggeridge not to use the term (2007:14) ‘Soft-face’). Interaction design, then named a current pressing concern for industry Cooper et al (2012:8) describe how:
“the user experience of digital products has become front page news…institutions such as Harvard Business School and Stanford have recognised the need to train the next generation of MBAs and technologists to incorporate design thinking into their business and development plans…Consumers are sending a clear message that what they want is good technology: technology that has been designed to provide a compelling and effective user experience.”
My key concern as a student of ID is that interaction Design is such a large area. Rogers et al (2013:9) list a dizzying array of areas:
“user interface design, software design, user-centered design, product design, web design, experience design, and interactive system design. Interaction design is increasingly being accepted as the umbrella term, covering all of these aspects.”
References
Papers
Patton, Jeff (2008), ‘A Conversation with Alan Cooper: The Origin of Interaction Design’
Software, IEEE Volume: 25 , Issue: 6, Page(s): 15 - 17
Johnson, J. ; Roberts, T.L. ; Verplank, W. ; Smith, D.C. ; Irby, C.H. ; Beard, M. ; Mackey, K. (1989) ‘The Xerox Star: a retrospective’
Computer Volume: 22 , Issue: 9, Page(s): 11 - 26
Grudin, J. (2012) ‘Introduction: A moving target-The evolution of human-computer interaction.’
To appear in Jacko, J., Ed., Human-Computer Interaction Handbook: Fundamentals, evolving technologies, and emerging applications, 3rd ed., Taylor and Francis.
Weiser M (1991) ‘The computer for the 21st Century’.
Scientific American 265(3):94–104, 1991
Books
Cooper A, Reimann R, Cronin D ‘About Face 3: The Essentials of Interaction Design’
John Wiley & Sons, 12 June 2012
Rogers, Yvonne ‘HCI Theory: Classical, Modern, and Contemporary’
Morgan & Claypool Publishers, Pennsylvania State University Press 1 June 2012
Moggridge, Bill (2007): Designing Interactions. The MIT Press 2007
Web
Sutherland, I.E. (1963/2003). ‘Sketchpad, A Man-Machine Graphical Communication System. PhD Thesis at Massachusetts Institute of Technology’,
online version and editors’ introduction by A. F. Blackwell & K. Rodden. Technical Report 574. Cambridge University Computer Laboratory [http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-574.pdf]
Programming languages let their users feel terrible or smooth just like GUI designing does. When it comes with bad syntax features, users endure it with twitching fingers and eyes. And such issues already wasted a lot of time and other resources due to wars between language's fans and opponents ( ex: "goto considered harmful", "Node.js is cancer" ... ).
I wonder why UI designing at least became a researching target and own some stable standard like the distance between of user's mouse and the target component while languages didn't. I know some issues related to semantics, not only syntax. But I seriously feel these arguments should be formalized by some strong enough standards.
It seems there is a course at Cambridge entitled "Usability of Programming Languages" that addresses this exact issue.
From the 2015-16 course page:
A programming language is essentially a means of
communicating between humans and computers. Traditional computer
science research has studied the machine end of the communications
link at great length, but there is a shortage of knowledge and
research methods for understanding the human end of the link. This
course provides practical research skills necessary to make advances
in this essential field.
The same page lists the following recommended reading:
Online proceedings of the Psychology of Programming Interest Group
Cambridge guidance for human participants in technology research
Cairns, P. and Cox, A.L. (2008) Research Methods for Human-Computer Interaction. Cambridge University Press.
Hoc, J.M, Green , T.R.G, Samurcay, R and Gilmore, D.J (Eds.) (1990) Psychology of Programming. Academic Press.
Carroll, J.M. (Ed) (2003). HCI Models, Theories and Frameworks: Toward a multidisciplinary science. Morgan Kaufmann.
The 2015 lecture notes seem like a good place to start: http://www.cl.cam.ac.uk/teaching/1415/P201/p201-lecturenotes-2015.pdf
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
It is a well known fact that IT projects fail with an alarming rate (some surveys suggest that the failure rate is more than 60%). Typically, project managers try to "recover" from these failures either by squeezing their resources to work extra hours or by compromising the quality of the deliverables (reduce testing effort, reduce scope etc.). Unfortunately, software quality is not deemed as very important by the business leaders.
I wonder if this is true about other professions as well ? How are projects managed, for example, in the construction industry where the cost of failures is very high and where a single mistake can be catastrophic ? Mega engineering projects like the Eurotunnel and Petronas towers required thousands of people and billions of dollars to construct and yet most of these projects were completed successfully within or sometimes even before time.
Are there some lessons we can learn on how projects are planned and managed in other industries ?
I think the biggest difference is that they would never consider starting a project with the same kind of shoddy requirements we are given. Maybe we should stop doing so as well and force people to actually define what they want before we start trying to code it.
I wanted to add that we as an industry to a lousy job of pushing back with a new timeline and budget when the requirements (such as they are) change. We started to do much more of this pushback here, telling the customer how many more hours (and more money) the requested change would take, adding the two extra days to do the the exisitng deadline and making them formally put in a request for change. The number of requested changes to intial requirments dropped drastically once we insisted there would be a cost for the change. This change also moved us from a cost center to a profit center in the company as we were doing a lot of extra work but not charging the customer more than the intial estimate.
Let's take a bridge as an example, and compare it with software.
The bridge will have fewer external specifications. It will have some pretty exacting specifications, but a lot of those will be internal (such as material strengths).
It will be designed by people who know that bridge design is not to be excessively rushed. In general, civil engineers will get more respect from their management than software developers. The civil engineers will in addition be working in a much more constrained problem space. There aren't nearly as many ways to make a bridge as an inventory system.
When the design is done, one or more licensed professional engineers will sign off on it. This is accepting real responsibility. (Alternately, no PE will bet his or her license on its soundness, and the design won't go anywhere.) This doesn't happen in software, partly because the problem space is so unconstrained.
Finally, the bridge will be built, and this will take months and a lot of heavy equipment. Software will be built initially with a compiler and reproduced indefinitely with cheap tools. There is a great psychological significance here: people tend to think of projects as having significant design and significant manufacturing stages, and if manufacturing is too trivial tend to think of part of the design as manufacturing.
If software were to be more like civil engineering, we'd need standard practices, adequate and reliable, for most things. We'd need engineers to study those practices, and be willing to certify that software either was or was not designed properly, and in fact we'd need projects done according to those practices to be almost completely reliable. We'd need more formal assumption of responsibility there. We'd need more external respect, because managers that will not dare throw away a $10 million construction project by meddling will often have no qualms about messing up a $20 million software project.
In short, software is too immature a discipline to work like civil engineering.
A lesson that can be learned from engineering: respect the non-functional requirements.
Functional requirements are hard enough, as they expect the users, developers, analysts and anyone else involved to be able to define what is needed to do business.
Non-functional requirements are the things engineers and technical people come up with that functional people may be blind to. It's very easy to overlook or downplay the non-functionals. Some PMs I've worked with in the past did not want to hear about non-functionals because they couldn't directly be tied to business needs and introduced tasks that would threaten the metrics of "on time and on budget".
Example
Functional requirement: Luxury ship must be able to carry X amount of passengers
Non-functional requirement: Ship big enough to carry X amount of passengers needs to have hull Y units thick to sustain integrity even upon impact with icebergs
Counting the Cost
Why don't software PMs respect non-functional requirements? Because the cost for such disrespect is different for engineering than it is for software development.
Cost of disregard for non-functional requirements in my ship example: loss of life.
Cost of disregard for non-functionals in software: some wimpy thing called technical debt, which will later be paid for by people long removed from the project team and the project team's completion bonuses.
Granted my examples are simplistic. Not all engineering foibles lead to death while some faulty software certainly can (avionics, medical, or traffic control systems being a few examples). But I think you get the idea.
There is a difference between software development and engineering or contruction industry - a specification always can be changed.
Walking on water and developing
software from a specification are easy
if both are frozen.
-- Edward V Berard (from here)
You can find more detailed explanation of differences in approach to project management at the beginning of the "Extreme Programming Applied" book.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Anyone know of a good book on
Game Interface Design (not game play mechanics; the actual UI).
I'm particular interested in theories of cognition, and how game interfaces are designed to allow the enduser efficient communication with the game (whether it in FPS, RTS, or so on).
In a modern game, the amount of information conveyed to the user,
the amount of choices the user can make; and the support for the
user to make said decisions is simply astounding (think UIs for Starcraft II / WoW).
Any insights into this would be greatly appreciated.
More a general interface design book, but great never the less.
http://www.amazon.com/Designing-Interfaces-Patterns-Effective-Interaction/dp/0596008031/ref=sr_1_3?ie=UTF8&s=books&qid=1268194286&sr=8-3
Unfortunally, there are not much info on that...
What I did myself, was study regular books about interface, or user interaction.
But you need to remember something: Altough the player should not ever be "challenged" by the interface, the interface must NOT make the challenge of of the game easier.
Several Game Design books, has some chapters dedicated to interface (I know that this is too little, but is the best we have for now).
I can recommend those:
Francois Dominic Laramee, Game Design Perspectives. Charles River Media, 2002. ISBN 1584500905.
Andrew Rollings and Ernest Adams, Andrew Rollings and Ernest Adams on Game Design. "Creating the User Experience" and each of the genre-specific chapters: New Riders, 2003. ISBN 1592730019.
Editor: Marc Saltzman, Game Design: Secrets of the Sages. "Chapter 12, The All-Important User Interface (UI) and Game Control," and "Chapter 15: Testing." 2 ed. Bradygames, USA, 2000. ISBN 1566869870
Some generic user interface books:
Wilbert O. Galitz, The Essential Guide to User Interface Design. 2 ed. Wiley 2002. ISBN 0471084646.
Doug A. Bowman, Ernst Kruijff, Joseph J. LaViola, Ivan Poupyrev. 3D User Interfaces: Theory and Practice. Addison-Wesley Professional, 2004. ISBN 0201758679.
Game Development Essentials: Game Interface Design: http://www.amazon.com/exec/obidos/ASIN/1418016209/acmorg-20
Cool links:
David Krieger, "Designing a Good Interface."
http://www.gamespy.com/articles/491/491801p1.html
Zhan Ye. "Designing User Interfaces for Games"
http://www.ye-brothers.com/documents/gameui.pdf
Note: I did not read all those stuff completly, I used parts of them to study at university....
Hum...
I think that this is it.
I'm a video game interface designer. In my experience the best interfaces are produced by good graphic designers, its not something you can solve theoretically. CodeMasters have created some of the best interfaces for games in their Dirt series, they have / had an in house central team of graphic designers with commercial graphics experience outside of games.
I know you're looking for UI and cognitive rules you can follow but I don't think it will help you. If you're really interested the best place to learn interface design is probably Vimeo :)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I spent a couple of hours to find any up-to-date figures regarding the share of software development methodologies such as Waterfall, RUP or Scrum but could not find any useful information. Is there anybody who knows about such surveys? The corresponding document does not need to be freely available, but as a matter of course I would appreciate it.
Thank you very much!
Seb
Couple of the documents I have on hand to help you on your research.
THE INFLUENCE OF ORGANIZATIONAL STRUCTURE ON SOFTWARE QUALITY: AN EMPIRICAL CASE STUDY
Nachiappan Nagappan
Microsoft Research
Redmond, WA, USA
nachin at microsoft.com
Brendan Murphy
Microsoft Research
Cambridge, UK
bmurphy at microsoft.com
Victor R. Basili
University of Maryland
College Park, MD, USA
basili at cs.umd.edu
In Proceedings, International Conference on Software Engineering, 1999, Los Angeles, CA, pp. 85-95
Splitting the Organization and Integrating the Code:
Conway's Law Revisited
Debugging the Development Process
Managing Humans - Biting and Humorous Tales of a Software Engineering Manager
I believe you will find most software developed for business systems follows iterative development cycles with a rough methodology similar to SCRUM even though most wouldn't have realized it.
The only times you will ever see a static methodology such as Waterfall would be in most likely a large government project that requires every single technical and business design document to be completed and approved before any type of software development begins.
Since you are willing to spend money, you could turn to a professional analyst firm like Gartner Research. They generate tons of reports and you might find something in their archives. Major corporations often cite studies by Gartner.
If that does not yield any results, you should do a search in research papers. Google Scholar might help you there.
If all else fails, and you have enough time on your hands, you could perform a small study yourself: Pick random companies and tell them you are doing research and that you would like to ask them a few questions.
If such a thing existed...
There would be standards based on the results. If anywhere close to 50% of shops actually used Scrum or RUP or anything, there would be an applicable standards organization pounding out the details.
We'd all be told specifically what to do based on the results. Our lawyers and accountants would ask why we're using a methodology only used by 15% and not a methodology used by 28%. We'd have to contend with armchair generals quoting the results at us.
There would be products for sale based on the results. "Supporting the most popular methodology." "One of the most popular methodologies." "Trouble-tickets for the fastest growing methodology."
You'd see advertising that quoted the results and claiming specific quantitative benefits. "28% of organizations use our version of Scrum with improved on-time delivery."
Ever see any advertising or standards based on adoption of a methodology? Anything?
Such quantitative studies probably don't exist.
Also, a precondition for counting is definition. Can you define Scrum in a way that it's somehow different from XP? I doubt it.
I think this kind of data cannot possibly exist. It requires far more formality and standardization than are even remotely possible for something so complex as software development.
I don't think you will find reliable data on what you're looking for. I've been looking for that kind of figures for a few years and I haven't found them.
First of all, very few organisations tell you what method they are using. Some just don't use any. Some other don't know what they use, or what to call it. And some know what to call it, but won't disclose it for whatever reasons. Of the organisations that will tell you, which are (in my experience) a minority, there's a big assymetry in how they characterise what they tell you. The way in which your own question is worded illustrates this: most industry people (and many academics) today, when asked to list methodologies, think of waterfall, RUP, Scrum, XP, and a few other "trademarked" agile approaches. It is interesting, but they are perfectly capable of citing a number of agile approaches, the differences between which are usually much smaller than the differences between (almost forgotten) methods that are bunched together under "waterfall". Agile approaches are so heavily marketed and hyped that, like Coca-Cola or McDonald's, are so present in our daily lives.
Methodologies are often presented as either waterfall or agile. That is a terrible fallacy, fostered by the agile community. There are successful methodologies that do not qualify as waterfall and predate (and do not qualify as) agile. However, they seem to be ignored, and they rarely surface on surveys such as the one you demand in your question. Very rarely I find people in industry reporting to use methods such as Catalysis, OPEN/Metis or Fusion.
(Note: Don't misunderstand me; I appreciate the value and contributions of the agile movement. But I am no raving fan; I am a researcher who tries to make an objective assessment.)
In summary, I don't think you'll find a study with data that answers your question. But, in your search, I suggest you take into account these comments.
Good luck. :-)
maybe not sound helpfull, but don't give to much to buzzwords. good programmer/software engineers with an sense/instinct what needs to be done you need. most of these proceses where invented because fearfull programmer sticked to closely to one of these pradigmes and the car went against the wall and some guy rightfully pointed out what they missed. but that can happen with most strategies if you don't see you situation in which you developing as a whole.
the more recently hyped methods like XP i don't see in you list. they work well even in smaller teams. :)