Why do people keep making this point. Design is the supposed solution to everything. It is false, plain and simple. Great APIs, great apps, great games ... do not start with a design. Here is how to write a great app :
1) have an idea. Execute that idea without any IT involved. Become a user of your non-existent app, so that you find the pain points.
2) write a bad app (this may require a "gather your thoughts" informal piece of text, 1st iteration maybe a paragraph, and from the 3rd iteration onwards maybe even a set of conventions and standards. Make sure everyone in the team adds something. Be encouraged to copy large amounts of code from previous iterations)
3) confront your bad app with the world, become a power user in your app, fixing bugs as you go
4) have your app confront a few others (ideally with them invested in it, ideally sell it)
5) think. collect your thoughts. Have a beer. Give it some time.
6) goto 1 (do NOT skip step 1, not even on the 10th iteration)
Repeat. On the 2nd iteration your app is a "reasonable" app. On the 5th iteration your app will be good. It is necessary to redo the task without any IT aid on occasion because that's how you find revolutionary ideas.
And the main antipattern is what I'd call "app management". You become a software engineer who thinks writing a database server is pretty much the same "process" as writing a html5 game. Like lots of managers think managing a software project is pretty much the same as managing a call center. You focus on requirements. You focus on design. "Best practices", preferably dozens of conflicting ones ("agile, yet controlled"). You focus on architecture. The truth is, if you have to gather requirements you have already lost, and you will not write a great app. If you want to write a great app, first you do the apps function yourself, personally, then you automate yourself back out again.
1 comment
[ 3.3 ms ] story [ 7.4 ms ] thread1) have an idea. Execute that idea without any IT involved. Become a user of your non-existent app, so that you find the pain points.
2) write a bad app (this may require a "gather your thoughts" informal piece of text, 1st iteration maybe a paragraph, and from the 3rd iteration onwards maybe even a set of conventions and standards. Make sure everyone in the team adds something. Be encouraged to copy large amounts of code from previous iterations)
3) confront your bad app with the world, become a power user in your app, fixing bugs as you go
4) have your app confront a few others (ideally with them invested in it, ideally sell it)
5) think. collect your thoughts. Have a beer. Give it some time.
6) goto 1 (do NOT skip step 1, not even on the 10th iteration)
Repeat. On the 2nd iteration your app is a "reasonable" app. On the 5th iteration your app will be good. It is necessary to redo the task without any IT aid on occasion because that's how you find revolutionary ideas.
And the main antipattern is what I'd call "app management". You become a software engineer who thinks writing a database server is pretty much the same "process" as writing a html5 game. Like lots of managers think managing a software project is pretty much the same as managing a call center. You focus on requirements. You focus on design. "Best practices", preferably dozens of conflicting ones ("agile, yet controlled"). You focus on architecture. The truth is, if you have to gather requirements you have already lost, and you will not write a great app. If you want to write a great app, first you do the apps function yourself, personally, then you automate yourself back out again.