The document outlines key aspects of software development, including both technical and non-technical considerations such as analysis, testing, and team selection. It emphasizes the Agile manifesto values, the importance of user stories and feature roadmaps, as well as cost analysis and scaling strategies. Additionally, it discusses the pros and cons of in-house versus outsourced development, highlighting that successful software development fundamentally relies on effective team collaboration.

1. The “Art” of Software Development
Arthit “Art” Hongchintakul
Managing Director
Swiftlet Co., Ltd.
contact@swiftlet.co.th

2. Agenda
Technical Aspect
> Some Propaganda Message
> What is Software Development?
> Inception
> Analysis
> Testing
> Development
> Release
Non-Technical Aspect
> Cost Analysis
> Scaling
> Tool Selection
> Development Team Selection

3. Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
http://agilemanifesto.org/

4. What is Software Development?
https://twitter.com/daisyowl/status/841806379962646532?lang=en

5. Inception
At the heart of the software, there is a purpose. Everything else
makes it more convenient to achieve that purpose.
> I want to connect all the people in the world
> I want to let developers collaborate
> I want to fix the taxi problems
> I want the blinds to spend leisure time as conveniently as
others.

6. Software Analysis
> From Inception, figure out what to do to achieve your goal.
> This becomes a feature.
> Then figure out what to do to achieve each feature.
> And so on.
> Until you find a starting point.
> This gives you a feature roadmap

7. Formalize the Analysis
> Once you have at least some part of the feature roadmap,
formalize it into a user story.
> A user story has one unit of business value.
As an authenticated user
I want to see a notification when the bus nears the pick-up point
So that I can prepare to drop my child off.

8. A user story
> Business value. 1 unit. No more, no less.
> Narrative
> Acceptance Criteria
Given I am an authenticated user
When the school bus reports its location near my pick-up point
Then I receive a notification on my phone
> Happy Path, error handling, edge cases.

9. A Good User Story: INVEST
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
> Independent
> Negotiable
> Valuable
> Estimable
> Small
> Testable

10. Vertical Slices
By Benjamin F Clay - Own work, CC BY-SA 3.0,
https://commons.wikimedia.org/w/index.php?curid=27808423

11. Estimation
> Give a story some amount of “points” of work required.
> Some use linear scale, some use Fibonacci scale.
> Some translate this “point” to work days. Some don’t.
> Choose what works best for you.
> Note that each team has their own value for 1 unit of this
“point” and they are almost always not equal, nor
convertible from one to another.
> How to estimate a story?

12. Rails Application Design
Model
Entity
Relationship
Validation
Indexing
Optimization
Behavior
Database Migration
Controller
Routing
Actions (Index, show, new, create, edit, update,
destroy)
Custom actions
Filters
Request Parameters
Authentication
Authorization
Response
View
Mobile Compatibility
Layout
Partials
Navigation
Structure
Content
Representation
Design
Behavior

13. Prioritization
https://en.wikipedia.org/wiki/Project_management_triangle

14. Feature Priority
> Must-have: We will lose without them.
> Should-have: We will not win without them.
> Nice-to-have: We will win more with them.
– I disagree on separating C, and W. If it’s unnecessary, it’s
unnecessary. They all fall into the “won’t do” bucket.
– Also, don’t fix things that don’t break.
– Also, keep it simple, and stupid.
– Elegance = Simple and Powerful
https://www.projectsmart.co.uk/moscow-method.php

15. Let’s Start Coding
Planbox (Own work) [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)],
via Wikimedia Commons

16. Software QA

17. Development Tools
> Algorithms (Neural Network, Dijkstra, Divide-and-Conquer, Shazam)
> Design Patterns (Abstract Factory, Builder, Object Pool)
> Architecture (Monolithic, Microservices, SOA, Serverless)
> Frameworks
– Server-side (Ruby on Rails, Django, .NET MVC)
– Front-end (Angular, React.js, React Native, iOS, Android, .NET)
– UI (Bootstrap, Sass, Less)
> Design tools (Moqups, UXPin, Sketch, Adobe XD)
> Source Control Management (Git, SVN, Mercurial) (Github, Bitbucket,
Gitlab)
> It a candy mountain!

18. Open Source Software
> Freely available vs Open Source
> License and cost consideration
> Huge benefit to you and the community; even though you
didn’t contribute.
– Bugs, issues, custom modifications
– Security
– Optimization
> Even more benefit if you do contribute.

19. Releasing Software
> Release Planning; Staging environment is essential.
> Release Process
– Code freeze (release branching, tagging)
– Pre-deploy QA
– Deployment planning; server deployment; app submission
– Post-deploy QA
– Rollback or other contingency
> Continuous Integration; Continuous Delivery

20. Software Development Cost Analysis
> Qualification: ISO, CMMA, Scrum
> Equipment: dev machines, test devices, licensing, various
environments, test platforms
> Labor: Project Manager, Analyst, Developer, QA,
Sysadmin/DevOps, Support
> Maintenance Cost: Domain, DNS, SSL Certificates, Hosting,
Analytics, Live Chat
> Disaster Cost: bugs, downtime, SLA, Opportunity Cost,
Reputation

21. Scaling
> How does your software respond to increasing load?
– Algorithmic analysis: Big O notation
– Load Testing: Jmeter, flood.io
> What is your expected load at launch? A month in? A year in?
Three years in?
> What kind of infrastructure you need to support such load?
> Real-time load monitoring – preemptive scaling
– New Relic, Zabbix, m/monit
> Cloud Infrastructure vs Hosted Solutions vs Self-Hosting

22. Tool Selection
> What is your goal?
> What is your constraint? Technical? Legal? Social? Management?
> What is your scaling plan?
> What platform are you running on?
> What kind of development resource do you have?
> Consult Google, Wikipedia, StackOverflow, Quora
> This new language/platform/framework is so cool! NO!

23. In-house vs Outsource
In-house
> You pay for the salary and all the
tools required. Sometimes with food,
other times with stock options.
> There’s no lump sum fee you can fix.
You will have to pay the price for
letting your staff go after the project.
> You have complete control over the
project. It’s entirely up to you, good
or bad, right or wrong, success or
failure. You had better know what
you’re up to.
Outsource
> You pay for the (greatly varying)
service fee and huge margin. You
have the power to choose a lump
sum fee; or a man-hour rate
> You usually have to have a
maintenance contract post-release.
> You have less control. Sometimes it’s
a good thing. Let the expert do their
job. Or… you may be conned in the
most terrible way.
Ultimately, software development is a people business. It all about who you hire.

24. Thank you
Any questions?