Nuway Software

NUWAY SOFTWARE

NUWAY SOFTWARE

Part 1: The "Old" Way

Part 1: The "Old" Way

Nuway's founders have worked in all aspects of

Nuway's founders have worked in all aspects of software develsoftware development:opment:

•

• Contractors for professional services companiesContractors for professional services companies

•

• In-house development teamIn-house development team

•

• IndepIndependent endent consuconsultantltants s evalevaluating uating vendvendors ors & & proprofessiofessional nal servserviceice

companies companies

We've seen it all, and haven't liked what we've seen !here is something We've seen it all, and haven't liked what we've seen !here is something fundamentally wrong with the current way software is "eing "uilt:

fundamentally wrong with the current way software is "eing "uilt: Professional services

Professional services

In this environment software is written as #uickly as possi"le $ery often In this environment software is written as #uickly as possi"le $ery often sh

shorortctcututs s wiwith th shshorort-t-teterrm m gagain in anand d lolong-ng-teterrm m papain in anand d arare e tatakkenen  !h!hisis creates a messy, di%cult code "ase on which the solution will rely ince creates a messy, di%cult code "ase on which the solution will rely ince customers typically never look under the hood to see the code, they have no customers typically never look under the hood to see the code, they have no idea how poorly things are running

idea how poorly things are running ater

ater, , when when "usin"usiness ess needs change, needs change, the the softsoftwarware e changechanges s are e(trare e(tremelemelyy e(pensive to implement in lieu of the amount of

e(pensive to implement in lieu of the amount of code that must "e rewrittencode that must "e rewritten  !he suggested

 !he suggested solution) * solution) * complete rewrite o complete rewrite o who "ene+ts who "ene+ts from this from this shortshort sightedness)

sightedness)

n!hose develo#$ent n!hose develo#$ent er

ere, e, devdeveloeloperpers s typtypicicallally y skiskip p doidoing ng prpropeoper r desdesign ign and and docdocumeumentantatiotionn "ef

"eforore e codcoding ing sinsince ce thethere re arare e no no sigsign n o o poipointsnts  !hi!his s makmakes es it it virvirtuatuallylly impossi"le to estimate the amount of work and stick to a schedule !his impossi"le to estimate the amount of work and stick to a schedule !his

leads to cryptic solutions that only the original author understands In developer circles this is often seen as .o" security: /I can't "e laid o if no one else can change my code/

With the development team resources always availa"le onsite, there is less of an emphasis on developing 0ero *dministration systems !his approach leads to having valua"le resources maintaining solutions rather than working on new pro.ects

n %oth cases

1very team of developers seems to have their own way of doing things, namely their /development methodology/ 1ven not having a structured development methodology is, itself, a methodology ome of these development methodologies are "ased on a pick & choose approach of  standard practices 2thers are .ust /we've always done it this way/ !he lack of an esta"lished and consistent development methodology causes pro.ects to "e unsuccessful 3late, over "udget, 4awed5 yet customers are rarely in a position to understand why

Par

t

2:

The

Nuway

6ncover the issues with the /old/ way What if there &as a ne& &ay'

• What if software could "e consistently delivered on time)

• What if software always met the user's needs)

• What if software could "e "uilt faster)

• What if we could look at the mistakes of the last decade and take a

dierent path to avoid them)

The N&ayT(

• )o t Ri*ht the First Ti$e

oftware isn't /developed/, it's constructed 7iano skills are developed gradually with lessons oftware is constructed, like an o%ce tower, at one time "ased on a "lueprint 8uality software starts with a #uality "lueprint oftware "lueprints are an art as much as a science !here is a "eauty and an elegance in simple designs It takes a senior developer with years of  e(perience to draft simple e(tenda"le solutions to comple( pro"lems 9unior developers are shorter sighted, "ecoming the authors of convoluted systems with large maintenance costs

 !he "lueprint is a critical step "ut only half of the entire formula for successful application creation 1ven the right "lueprint in the wrong hands will never result in a #uality product any may claim to "e a"le to get the  .o" done, few pursue the path of Craftsmanship

It is not .ust a matter of doing what is in the "lueprint 3the plan5; it is a"out achieving near perfection In home construction, taking shortcuts leads to s#ueaky 4oors and popping drywall plugs In software creation, shortcuts

lead to poor application performance, e(cessive use of cellular data transfer, "ugs, and high cost of change

* true craftsman will appear to cost more up front !he primary reason for that is they are guaranteeing the solution will "e done right the +rst time Craftsmanship results in a higher #uality solution with a lower overall cost We follow the 6ni+ed oftware <evelopment 7rocess, an industry leading development methodology with proven success !his process was originally developed "y =ational oftware, a think tank on how to "uild "etter software !hrough a recent ac#uisition it is now owned and operated "y I> >ecause this isn't something we /.ust made up/, our clients can rest assured their pro.ect is in the hands of e(perts

• Ti$e and +d*ets are $#ortant

oftware is useless unless it solves a speci+c pro"lem, within the "udget and "y a speci+c time 2ur e(perience and process allows us to accurately predict the cost and schedule of your solution and stick to it

• Soft&are Solves Pro%le$s

oftware isn't written for software's sake oftware solves pain points within an organi?ation If a feature cannot "e directly traced "ack to "ene+ting a user, it is dropped from the pro.ect

• ,ero (aintenance

olutions should "e self administrating: "y the users, for the users !he developer should "e a"le to easily remove his or herself from the daily operation of the system with no impact

• Partner With- Not Wor. For

 !o understand the "usiness pro"lem that must "e solved, we must completely understand the "usiness We partner with our clients "y learning their "usiness, how it runs, and designing seamless solutions that +t within the greater conte(t

Wh

at

i

s

a

So

f

t

wa

r

e

Pr

o

c

es

s

* software process, or methodology, de+nes the steps re#uired to create software successfully

 !he >rief istory of oftware 7rocess

 !eams have "een writing software since the @A's Clearly time has "rought a"out many improvements in technology, language, and tools While these advances are e(citing, the most important part of software construction is /the how/ not /with what/

In the late BA's, three engineers <r Ivar 9aco"son, rady >ooch, and <r  9ames =um"augh each pu"lished a software development process 1ach had its own strengths and weaknesses !he software industry fell into several camps, each holding to one of these methodologies as "etter than the other rady >ooch was a founding employee and chief scientist of =ational oftware In the mid DA's =ational successfully negotiated the addition of <r  9aco"son and <r =um"augh !he three leaders, aectionately called /!he  !hree *migos/, were now under the same roof and working together !heir

collective intellect "rought a"out two revolutions in software methodology  !he +rst was in EDD@ when they pu"lished the 6ni+ed odeling anguage

previously disparate forms of diagram notation Finally, a diagram could "e drawn and its intricacies immediately understood "y software developers across the world

 !he second achievement was in EDDB when the !hree *migos pu"lished the 6ni+ed oftware <evelopment 7rocess 3675 which was proprietarily implemented as the =ational 6ni+ed 7rocess 3=675 GA !his process com"ined the "est points of the three other processes into one cohesive whole that could guide a pro.ect successfully from inception to completion It would take several years for the signi+cance of these works to permeate the industry 1ven today many software teams are ignorant of these ground "reaking works

 !hree Complimentary ethodologies

 !o the uninitiated, these methodologies look to "e opposing News groups across the internet hold numerous de"ates on which method is "etter than the others !he truth is that they are wonderfully complementary, each addressing dierent aspects of the inherent di%culty constructing software Uni/ed Soft&are )evelo#$ent Process 0UP

 !here are four "asic principles of the uni+ed process: that software should stress use cases 3which show how it interacts with users5, that the process is architecture-centric, and that it is iterative and incremental 67 de+nes what steps and artifacts 3documents, diagrams5 should "e e(pected in the four phases of a pro.ect:

E Inception - 1arly analysis

H 1la"oration -- <etailed *nalysis and <esign  Construction -- 7rogramming

J !ransition -- <eployment & !raining E2tre$e Pro*ra$$in* 03P

 !he three fundamental points of Kent >eck's 1(treme 7rogramming are: that changes can "e made to software "oth early and late in development with no increase in workload, that code should "e written in pairs so it is constantly under peer review, and that software should "e implemented as simply as possi"le 3no over engineering in anticipation of future uses5

(icrosoft Soltions Fra$e&or. 0(SF

2"viously icrosoft has "een writing large scale software for over HA years undreds of thousands of software developers are enlisted in their icrosoft <eveloper Network in addition to their Certi+cation programs !he latest version of F provides a 4e(i"le framework for organi?ing a team, the roles, and responsi"ilities throughout a pro.ect

ummary

 !he customi?a"le nature of these processes and their dierent focuses allows them to "e com"ined into a cohesive whole within an organi?ation

Nuway'

s

Pr

ocess

Nuway oftware follows the 6ni+ed oftware <evelopment 7rocess 3675 We use 6 to diagram and visually represent aspects of the system ost clients are unfamiliar with 6 and we are very happy to educate them "efore initiating the pro.ect

2ur proprietary Nu<oc documentation technology allows us to communicate e%ciently throughout the pro.ect !his format was developed after years of e(perience and client feed"ack Nu<oc eliminates the reading of out dated

documentation, confusion of what changes were made, and losing track of  feed"ack or notes

 !he following synopsis outlines what our clients can e(pect as we work together on the pro.ect * speci+c road map is provided upon commencement of a pro.ect

7hase E Inception

<uring this phase, a good idea is developed into a vision of the end product and the "usiness case for the product is presented 1ssentially, this phase

answers the following #uestions:

What is the system primarily going to do for each of its ma.or users) What could an architecture for that system look like) What is the plan and what will it costs to develop the product)

* simpli+ed document that contains the most critical use cases answers the +rst #uestion *t this stage the architecture is tentative It is typically .ust an outline containing the most crucial su"systems In this phase, the most important risks are identi+ed and prioriti?ed, the ela"oration phase is planned in detail, and the whole pro.ect is roughly estimated

7hase H 1la"oration

<uring the ela"oration phase, most of the product's use cases are speci+ed in detail ost importantly, the system architecture is designed !he architecture is e(pressed as several diagrams of the system, which together represent the whole system !he analysis of the implementation model includes components to prove that the architecture is e(ecuta"le It is imperative that the construction phase not "egin until the architecture is sta"le

<uring the construction phase the product is "uilt <uring this phase of  development, the "ulk of the re#uired resources is e(pended !he architecture of the system is sta"le, however, "ecause the constructors may discover "etter ways of structuring the system, they may suggest minor architectural changes to the architects *t the end of this phase, the product contains all the use cases that management and the customer agreed to develop for this release

7hase J !ransition

 !his phase covers the period during which the product moves into "eta release 3typically to a soft-release environment5 * small num"er of  e(perienced users try the product and report defects and de+ciencies Constructors then correct the reported pro"lems 6ser documentation and training are provided during this period

Ab

ou

t

Cr

a

f

t

s

ma

ns

h

i

p

Nuway is committed to "ringing craftsmanship and raising the "ar in the profession >elow we descri"e how we "elieve software should "e written We unashamedly share our opinion of what is wrong within our industry owever, criticism without care for solutions is of no more "ene+t than a clanging gong or a crashing sym"ol: it's loud and annoying to everyone

any clients want to outsource a single pro.ect, "ut take over the support and future changes when it is completed In this case the #uality of the code and its a"ility to "e easily understood "y new people is of utmost importance * vendor who may "e the cheapest up front may cost tens or even hundreds of thousands of dollars later in wasted time and eort as the receiving team tries to understand the code, or spends time replacing poorly written parts

What we mean "y Craftsmanship

Craftsmanship is the fusion of attitude and competency

*ttitude is one's personal motivation to doing their "est Craftsmanship takes eort Craftsmanship re#uires discipline !he right attitude fuels the hard clim" necessary to learn improved ways of doing things ome people want to do well, "ut never put in the eort In this case their actions "etray their true mind-set

Competency is one's a"ility or skill in a +eld Competency comes from many paths: natural talent, education, trial and error, and e(perience over time =egardless of how it comes, competency is the e(tent of control someone has on achieving their desired result omeone may desperately want to play o?art on the piano, "ut if they haven't taken any lessons, the goal is simply out of grasp

 !he mark of a craftsman is someone with a wealth of e(perience, demonstrated a"ility, and a strong desire to do "etter ne(t time

Why Craftsmanship Counts

oftware construction is a continual process of choosing one way forward from do?ens 3or hundreds5 of possi"ilities *ll of these choices stack and ultimately "ecome the +nished product * person with the right attitude will evaluate many paths "efore deciding the "est one !he +rst readily apparent answer is often the wrong one * person with high competency knows of  many more possi"le paths and which ones are dead ends

 !he two ma.or places where craftsmanship counts are performance and e(tendi"ility

Well crafted software runs fast !here is no /"loat/ of useless processing or unnecessary calculations For instance, looking up information in a data"ase

can "e done once or re#uire several round trips !he many round trips could "e GA( slower, "ut it is easier to program When many shortcuts like this are taken the software suddenly only runs on high-end hardware, or doesn't allow remote users to work eectively Now poor craftsmanship is costing the client money

Well crafted code is easy to change and e(tend, even "y someone who didn't previously work on the system When all of the classes in the code have meaningful names and follow proper rules of encapsulation, it's a #uick and pleasura"le e(perience to add additional functionality If the code resem"les /spaghetti/ it will take a long time to make the change and s#uash all the resulting "ugs Now poor craftsmanship is costing the client money in unnecessary eort

 !he =ight way to Write Code

O%4ect Oriented Pro*ra$$in* 0OOP thro*h )esi*n Patterns

ost, if not all, programming tasks can "e "oiled down to a generic pro"lem It is likely these generic pro"lems have already "een solved !he solution to a generic programming pro"lem is called a <esign 7attern !he use of design patterns ensures you are solving a pro"lem correctly, in a way that will scale, and you won't run into unforeseen road"locks in the future

Self!)oc$entin* 5ode

Nuway writes clean code Code that self-documents as much as possi"le In practice this looks like:

E =outine names descri"e e(actly what the routine does, with $er"Noun naming convention

H 1ach routine performs one well-de+ned task If a routine does only one thing, it's easy to +nd a pro"lem or know where to make a change

 $aria"le names are descriptive of the "usiness value they contain, not things like: var, val, i, ., etc

J pecial values are enumerated or stored as constants instead of  /magic num"ers/

o i?e LL 7i??ai?earge is clearer than i?e LL EH

5ode 5o$$ents

When code isn't clear through self-documenting 3see a"ove5, Nuway provides the relevant comments !his is #uality, not #uantity We a"ide "y the following principles when commenting:

E Clarify the intent of the code, don't e(plain what it does

H Whenever a decision is "eing made in the code, e(plain why  <ocument any speciali?ed knowledge

o If an e(ternal *7I re#uires calling two methods in a particular order to

work this must "e captured for future reference when someone is doing maintenance

J Comment anything that gets around an error or an undocumented feature in a language or environment

o If you've discovered a !C7 listening routine doesn't handle e(actly EAHG

"ytes, "ut all other values are +ne, make a note of it

G If utili?ing a <esign 7attern, document which one it is and where it came from 32F, <N, 1tc5

Refactorin*

 !ypically your +rst attempt at something is never your "est * second pass will typically show "etter ways of accomplishing the same goal =ewriting your code a second time is called refactoring !his isn't something left to the end /when I have time/, it's part of the process Mou refactor as you go !he rules used in refactoring are e(tensive, "ut the reason Nuway practices it are:

E Improves the design of software

H akes software easier to understand  elps you +nd "ugs

J elps you program faster Notation

Nuway follows the icrosoft standards for programming notation !he purpose is to make the software code look as much like icrosoft's so you don't have to switch mental gears as you read

E In C, we use camel case notation G

H In COO we use ungarian notation P

Test )riven )esi*n

 !he most e(pensive part of a software change is the veri+cation the change didn't "reak anything !his veri+cation is called =egression !esting !est <riven <esign eliminates the need for regression testing, there"y 4attening the cost of change

 !he process was populari?ed "y the agile development process eQtreme 7rogramming 3Q75 !est driven design means the programmers write automated tests that check the code to make certain it is still correct *s the

team "uilds the total pro.ect, all the individual tests "uild up into an e(tensive arsenal of tests that can very #uickly guarantee the entire system is operating correctly !his is critical to reducing the cost of changes in the future Now a change can "e made, the automated tests run, and the integrity of the system veri+ed without copious amounts of manual la"our )oc$entation

Following the 67 generates a lot of working documentation *ll this documentation is in 6 , the industry standard notation 2ur documentation includes:

E 6se Case diagrams - to show stake holder ownership and system scope H *ctivity <iagrams - to show comple( "usiness rule "ranching

 Class <iagrams - to show system design and interaction J e#uence <iagrams - to show per use case message 4ow

Sorces

E 1rich amma, =ichard elms, =alph 9ohnson, and 9ohn $lissides, <esign 7atterns: 1lements of =eusa"le 2".ect-2riented oftware, *ddison Wesley, EDDG

H teve cConnell, Code Complete, icrosoft 7ress, EDD, JGP  teve cConnell, Code Complete, icrosoft 7ress, EDD, JBB

J artin Fowler, =efactoring: Improving the <esign of 1(isting Code, *ddison Wesley ongman, EDDD

G /Naming uidelines/, N1! Framework eneral =eference, <N, HAAG P /$aria"le Names and ungarian Notation/, <N, EDDB

@ Kent >eck, eQtreme 7rogramming, *ddison Wesley, HAAA

Nuway

Guar

ant

ee

2ur wealth of e(perience fused with industry standard "est practices ena"les us to unashamedly guarantee:

•  Mou will understand speci+cally what your responsi"ilities are as a

client and what Nuway will look after

•  Mou will only need to identify "usiness needs, pro"lems, and pain

points; we take care of the rest

•  Mou will know precisely when the pro.ect will complete, not a day later

•  Mou will know e(actly what the pro.ect will cost, not a penny more

•  Mou will know the status of your pro.ect