Software Development An overview of careers in Business

Software Development An overview of careers in Business Application Development http: //goo. gl/3 go 6 re Sources: Dice. com, money. CNN. com, Info. World. com, money. USNews. com, Glass. Door. com, Indeed. com, OODesign. com, Los. Techies. com, myself

The Job Market Or… “How to win at life”

Jobs… jobs EVERYWHERE! • 120% growth over the last 4 years • Estimated 30% growth through 2020 • Jobs in every city • Demand for developers far exceeds supply

Who likes money? • Average salary of $92, 000+ • Salary starts lower, but scales quickly with experience. • Some of the highest disposable income is in Texas!

The most fun you can have at a desk (legally). • Flexible hours • Casual dress code • Fun environments • Beer and ping pong!

What is Software Development? No, really…

Consulting vs Product vs IT

git merge reality • Coding is only half the battle. • You must understand the needs of many different clients. • Development methodologies are part of the job.

Do you like Waze or Google Maps? • Agile (http: //agilemanifesto. org/) • Waterfall • XP • SCRUM • KANBAN

It’s all fun and games until someone uses REGEX. • Complexity comes from modeling the real world in code in a manageable way. • Complex algorithms are rarely needed. • Business requirements are often mundane.

Let’s just rewrite it… • Making WORKING code is easy • Making GOOD code is hard • Aim for Readability and Maintainability • Performance is rarely a concern

Principals of Software Development An overview of the tools we use in Business Application Development http: //goo. gl/3 go 6 re

TDD • Unit testing aids in bug finding and refactoring. • Writing tests first guarantees that code is tested and follows good design. • This process normally follows the Red->Green->Refactor workflow.

It’s dangerous to go alone! Take this. • DRY • SOLID Principals • Design Patterns • YAGNI • Standards/Conventions • Automated Testing/TDD • Pair Programming

Single Responsibility Principal • Each class should do ONE thing and only ONE thing. • Classes should be as small as possible. Then make them smaller.

SRP Example class Book { string get. Title()… } class Book { string get. Title(). . . string get. Author()… string get. Author(). . . void print. Current. Page()… string get. Current. Page() { return current. Page; } } class Printer { void Print. Page(string page) { Console. Print(page); } }

Open-Closed Principal • Classes should be open for extension, but closed for modification. • If you add functionality, you should be able to add code, not change existing code.

OCP Example class Sql { public Sql(string table)… public void Create()… public void Update()… { interface ISql { public Sql(string table)… public void Run()… { class Sql. Create : Sql { public void Run()… { class Sql. Delete : Sql { public void Run()… {

Liskov Substitution Principal • Derived types and base types should be compatible. • Derived classes should EXTEND base classes, not change them.

LSP Example class Rectangle { public int get. Width()… public void set. Width(int width)… public int get. Height()… public void set. Height(int height)… } class Square extends Rectangle { public void set. Width(int width) { m_width = width; m_height = width; } public int get. Area()… } public void set. Height(int height) { m_width = height; m_height = height; }

LSP Example continued… public void Set. Rectangle(Rectangle shape, int width, int height) { shape. set. Width(width); shape. set. Height(height); } // What happens if we pass this function a Square object?

Interface Segregation Principal • Interfaces should not be “fat”. • If you implement an interface, it should mean that you need the whole thing.

ISP Example interface IWorker { public void Work(); public void Eat(); } class Worker : IWorker { public void Work(); public void Eat(); } class Robot : IWorker { public void Work(); } interface IWorkable { public void Work(); } interface IFeedable() { public void Eat(); } class Robot : IWorkable { public void Work(); }

Dependency Inversion Principal • Higher level classes should depend on lower level classes. • Classes should depend on abstractions, not concretions.

DIP Example interface IPrinter { void Print. Page(); } class Console. Printer : IPrinter { void Print. Page(string page) { Console. Print(page); } } class Tree. Burner: IPrinter { void Print. Page(string page) { HPPrinter. Print(page); } } class Book. Printer { void Print. Book(Book book, IPrinter printer) { var page = book. get. Current. Page() while(page != null) { printer. Print. Page(page); page = book. get. Current. Page() } } }

Design Patterns • http: //www. dofactory. com/net/ design-patterns • Patterns provide solutions for common situations that follow best practices. • Patterns are easily recognizable by other developers.

Josh Rizzo Senior Consultant Improving Enterprises Josh. Rizzo@Improving. Enterprises. com