'Having plans for a software product sometime in the future, I would like to know the best way to design a software product. Architecture (i.e. components and relations between components) first or the GUI?
Thanks.
+3
A:
I'd say there is no difference. If you have a skilled architect in your team - there would not be any problem developing both at the same time. If your architect is inexperienced - you will have lots of hassle either way.
Added: Given your comment, here is what should drive your choice:
1) If your project is highly feature oriented (for example some self-service system, maybe some bugtracker engine,etc., - anything that has complex functionality) - you should go with architecture first. Otherwise, you will find out that your complex architecture do not fit into the GUI you made, leading to GUI and architecture changes and lots of problems in future.
2) If your project is aimed to be highly user friendly, lets say something like facebook, last.fm or even stackoverflow.com - you should go with GUI first and architecture later. This way you will ensure that all the user-friendliness remains the same as it was designed by the cost of some additional hassle with architecture (architect will need to design architecture given the GUI).
Max
2010-08-19 11:32:54
Part of the problem is that I envision as a future startup I'd like to keep my costs as low as possible for as long as possible by only hiring talent when it becomes necessary to do so e.g. software developers don't get hired till the software architecture and engineering is complete. For the same reason, I was hoping I'd be able to put of hiring a GUI designer until the architecture is complete. Problem is that GUI issues crop up in the architecture. Then again, if the GUI designer was hire first, (s)he will require specs that only an architect can provide. Result: a chicken and egg problem.
Olumide
2010-08-19 11:52:21
@Olumide: I've changed my answer to include your case.
Max
2010-08-19 12:08:03
I suppose another way to go about it could be to have the architect prepare initial specs (e.g. list GUI components) and then bring a designer on board to realize the GUI to life and raise hidden issues.
Olumide
2010-08-19 14:31:35
Generally, IMO, if there is "10 units of architecture work" in a project, there is about that much whether you do it all up-front or iteratively. If you imagine that there's some "overspend", there's usually more overspend if all is done up-front; misunderstanding are bigger and more intensive to correct. Agile techniques have been instrumental in delivering just enough just in time for many teams.
alphadogg
2010-08-21 12:41:06
+2
A:
Sketching or prototyping the GUI and discussing it with your team (or customer for customer projects) can clarify the domain model behind and reveal a whole lot of business rules and requirements that would have been ignored otherwise.
Whether or not you do the eventual GUI design later on still remains open, but not thinking about the interface at all before designing the architecture is IMHO somewhat risky.
chiccodoro
2010-08-19 12:12:35
Thanks. However the problem is that the software is not being developed for a specific client but rather for general sale. As such, there are no ready-made reaquirements.
Olumide
2010-08-19 14:23:47
@Olumide: You're right, you've written that. However the principle remains the same (will update the answer): When you do workshops with your creative brains, thinking about the interface will help shaping the requirements and domain model IMHO.
chiccodoro
2010-10-05 06:38:59
A:
An GUI can help the architect both capture as well understand business requirements especially those that may not be explicitly captured by the user as part of requirements documentation.
To cite an example: In one of our application requirements, the user mentioned having sets of data entry fields grouped together - based on some business logic. Since when doing the GUI, it was decided that the groups should not be visible all at once and a tab page kind of structure was preferred for display, usability questions like data to be retained by the application when moving across the tabs, technical questions like should all the tabs be loaded at once or on demand etc were obvious to the architect. Clarification of these questions user interface resulted in the architecture having to accomodate various means to meet these requirements.
I do think that desigining the UI first and having it as a reference when working on the architecture is a better option if that choice is available.
InSane
2010-08-19 12:30:47
+1
A:
I think it depends on the type of your software. Usually I would like to confirm the most difficult part first. If your software GUI (and interaction?) will be complex and important, I would suggest to design the GUI (and interaction) first. (e.g. you are designing a painting tool or text editing tool)
Xavier Young
2010-08-21 12:33:08
A:
For a while i thought the correct answer was 'architecture'.
True story: about four years ago, I presenting the architecture for a software project to the executive team as part of our quarterly budget review process. The project didn't get funded. Later, i asked why; one of the execs told me that no one knew what i was talking about, nor was it clear to them how much work had been done, nor how much was left to do--'too uncertain' they concluded.
About a year later, i gave another set of project summaries at the quarterly budget review. Having learned a valuable lesson, this time, for my group's most significant early-stage project, i showed a GUI--little more than a wireframe for the main dashboard in which only a few of the buttons were actually clickable, followed by a set of wireframes for each of the main sub-directories. For two days (and nights) work, our guys did an excellent job--clearly i was able to show the executive team exactly what the app would do.
The result: not funded. i asked one of the execs why--he said "well it seemed to us you've got a complete application--we didn't see that there was any development work left to do. And nice job by the way!'
Surely there's a lesson here, though i still have no idea what it is.
doug
2010-10-05 07:02:58