"Writing code isn't the problem, understanding the problem is the problem." (Curtis et al, 1988)Software engineering is the systematic production of software by teams of engineers. Software engineering is a well understood domain, it encompasses structured methodologies, industrial/organisational frameworks like RUP and CMMI, through to agile methods such as XP, SCRUM and others. We have moved beyond the era where writing code was seen to be the problem. We no longer agonise over how to organise software development. These things are well known, their limitations and potentials understood. In short, we can effectively and successfully address the management and organisational challenges of software engineering. So, if software engineering as a problem has been solved, what's the problem?
Interface, UX and interaction designers argue that our biggest challenge is how to design great products that are usable and valuable. Like the software architect in Curtis et al, Paul MacCready (designer of the Gossamer Condor, quoted in Raskin (2012)) argues that "the problem is we don’t understand the problem." His view is that design is a process in which the best strategy is to learn quickly, to discover what the problem is; to fail early and fail often.
...How well equipped are we therefore, to deal with the problem of "understanding the problem"? Is the real problem design and therefore designers or is it 'design as a process'?
References:
CURTIS, B., KRASNER, H. & ISCOE, N. 1988. A Field Study of the Software Design Process for Large Systems. Communications of the ACM, 31, 1268-1287.
Raskin, Aza. 2012. Blog post on Paul MacCready (link)
