Ted Patrick - Flash Platform @ Adobe Systems
Note: This is the personal blog of Ted Patrick. The opinions and statements voiced here are my own.
Development Unit by Unit
DIGG IT!
6
Comments
Published
Thursday, July 16, 2009
at
2:54 PM
.
When I write an application i tend to develop it in parts or units. At first I will focus on getting one part working and make sure to clearly understand its behavior, inputs, usability, and outputs. I will then move to assembling these units together into a larger application. In many ways it is very similar to Chafic's concept of Application Components where a larger application is technically made of many subcomponents that contain larger sets of working parts. 
I really like to both think and work on applications in parts as better interfaces (programming) result. I get one or two units of an application working and then merge them together into a larger build given unit stability and functionality are largely complete. Maybe it is my way of breaking problems down into smaller peices but it really helps me get to the end result quicker. Ideally I spend as little time as possible with a non-working app and rather focus on getting each unit working well before assembling these units together.
How do you build apps or parts of apps?
Cheers,
Ted :)
6 Responses to “Development Unit by Unit”
Post a CommentWhere to find me:
Ted on Twitter - @__ted__
Ted on Adobe Groups
Ted on LinkedIn
Ted on Facebook
Ted at Adobe
Latest
- Memory Performance in the Land of References
- Free Flex development Tools for out of work devs
- Design++
- Design an Application like a Movie
- My intellectual property and Why Adobe a great pla...
- Problem Solving
- Development Islands
- Development TODO Lists
- Where community and Catalyst meet
- Acrobat.com Presentations
Lists
Links
Jobs
Archives
- May 2003
- June 2003
- July 2003
- August 2003
- September 2003
- October 2003
- November 2003
- December 2003
- January 2004
- February 2004
- March 2004
- April 2004
- May 2004
- June 2004
- July 2004
- August 2004
- September 2004
- October 2004
- November 2004
- December 2004
- January 2005
- February 2005
- March 2005
- April 2005
- May 2005
- June 2005
- July 2005
- August 2005
- September 2005
- October 2005
- November 2005
- December 2005
- January 2006
- February 2006
- March 2006
- April 2006
- May 2006
- June 2006
- July 2006
- August 2006
- September 2006
- October 2006
- November 2006
- December 2006
- January 2007
- February 2007
- March 2007
- April 2007
- May 2007
- June 2007
- July 2007
- August 2007
- September 2007
- October 2007
- November 2007
- December 2007
- January 2008
- February 2008
- March 2008
- April 2008
- May 2008
- June 2008
- July 2008
- August 2008
- September 2008
- October 2008
- November 2008
- December 2008
- January 2009
- February 2009
- March 2009
- April 2009
- May 2009
- June 2009
- July 2009
- August 2009
- September 2009
- October 2009
- November 2009
- December 2009
- January 2010
- February 2010
- March 2010
- May 2010
- June 2010
- July 2010
Your development practice sounds a lot like basic, good problem solving techniques. i.e. Breaking problems into smaller, more manageable pieces.
I don't work with a team so I have more freedom in how I architect my code. I do code similarly to you though so for example I write my database read/write/update code into PHP classes first and then write the Flex UI which hooks into the backend I just wrote.
I plan things top-bottom, from big picture to small details, but I execute them in the other direction - bottom-top, from small working pieces of code (components) to big solutions of whole problem
basic divide and conquer
It's easy and it works in most of the cases.
I also end up with well-defined units, but take a markedly different approach to arrive there. I construct a "walking skeleton":
http://alistair.cockburn.us/Walking+skeleton
I also sometimes call it "embryonic development." Been meaning to blog about it some time.
Also, I use test-driven development to stress the design. I find the tests pull the software into shapes that are more optimal than I could plan.
Thats exactly I tend to tackle most or my apps, including twitcher. Its much quicker and easier to write an app that creates a new tooltip class (for example) in isolation; its quicker to build, debug and test. Then when its working, its componentised enough to slot into somewhere else.
I wish the Flex modules would make 'development unit by unit' easier... Now they're like an afterthought...