Stray Thoughts on App Development

Created on 2015-04-11 (Sat)

I found the following in an e-mail I sent to a friend. It contains my raw thoughts about what to consider when developing an app. I brushed it up here and there and then posted it for my future reference.

Identify what the application needs to do (start with user requirements, derive functional specifications and maybe some test cases to gauge if you satisfy the user requirements).

Define major modules (i.e. database interface, other hardware the app touches, com protocols, state machines used, error handling, data logging, are you using a model view controller pattern for the ui? etc)

Define data model (i.e. what the tables in a relational database are, superkeys, XML trees, whatever you use to store data, also include some kind of versioning system for your data model... It's going to come in handy later on.)

More recently this step has changed somewhat with the advances of the noSQL databases. It is still very important to take a first shot at defining a schema for your database.

Define "business logic" (start from the inputs and outputs of the system and work inwards, do you have any constraints on the data manipulation, once defined what are the constraints the system imposes on the users).

Design UI (umm... I guess there's way too much to talk about here).

Somewhere in between UI and data model there should be a well defined IO Protocol (i.e. this kind of data comes from the user and this comes from the database. Then the user can only see this kind of data in this particular format).

Resource management (how fast do you want you app to respond to UI input? Maybe you need to use some threads to make it feel smooth - if that's the case try to define what must stay on the main thread and what can be spun off in secondary threads, if you are on an embedded architecture start thinking about interrupt priority, how big can the stack be, are you running out of RAM or FLASH? Even on a desktop you probably don't wanna load a 1GiB data set and play with it in RAM.)

Security/networking (is this accessible over the intertubes? Can the data set be compromised by some malefic spirit? More networking related - what happens if the internets are not available - do you have elegant degradation of service or does the app blow in your face?)

Error processing and failure recovery. Where do you deal with the errors? Do you have a singleton that you pump errors to and that then becomes the decision nexus for what needs to happen next (I don't like this as it becomes a highly coupled element in the design - but sometimes it is needed) or do you deal with errors locally (this sometimes still requires a global Error object that stores all kind of error flags that needs to be checked upon by different modules of the app). Early on my UI didn't have consistent error conventions (i.e. a well defined error code structure) - and that made me feel kind of silly. Make sure you know which errors you detect and report without doing anything versus detect and try to correct. Are there any errors you can foresee (ie user input that's contradictory)?

Scalability (aha... This bit me quiet hard...) This is where you wanna make sure you decouple modules and have nice defined interfaces. Keep your data models independent from your data manipulation code. Use polymorphism to deal with different versions. Which modules are most likely to change? Throughout all this process remember that decoupling shifts the complexity from local to global.

I'm kind of done... This is raw brain dump and is all typed on iPhone so pardon the spelling and coherency.

I would probably just come up with a design and then subject it to an analysis that focuses on the areas above. Then implement some of it and repeat until satisfied.