NUWAY SOFTWARE

Part 1: The "Old" Way

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

Contractors for professional services companies

In-house development team

Independent consultants evaluating vendors & professional service

companies
We've seen it all, and haven't liked what we've seen. There is something
fundamentally wrong with the current way software is being built:
Professional services
In this environment software is written as quickly as possible. Very often
shortcuts with short-term gain and long-term pain and are taken. This
creates a messy, difficult code base on which the solution will rely. Since
customers typically never look under the hood to see the code, they have no
idea how poorly things are running.
Later, when business needs change, the software changes are extremely
expensive to implement in lieu of the amount of code that must be rewritten.
The suggested solution? A complete rewrite. So who benefits from this short
sightedness?
In-house development
Here, developers typically skip doing proper design and documentation
before coding since there are no sign off points. This makes it virtually
impossible to estimate the amount of work and stick to a schedule. This

leads to cryptic solutions that only the original author understands. In

developer circles this is often seen as job security: "I can't be laid off if no
one else can change my code."
With the development team resources always available onsite, there is less
of an emphasis on developing Zero Administration systems. This approach
leads to having valuable resources maintaining solutions rather than working
on new projects.
In both cases
Every team of developers seems to have their own way of doing things,
namely their "development methodology". Even not having a structured
development methodology is, itself, a methodology.

Some of these

development methodologies are based on a pick & choose approach of

standard practices. Others are just "we've always done it this way". The lack
of an established and consistent development methodology causes projects
to be unsuccessful (late, over budget, flawed) yet customers are rarely in a
position to understand why.

Part 2: The NuwayTM

Uncover the issues with the "old" way
What if there was a new way?

What if software could be consistently delivered on time?

What if software always met the user's needs?

What if software could be easily changed and extended, at any time?

What if software could be built faster?

What if we could look at the mistakes of the last decade and take a
different path to avoid them?

The NuwayTM

Do It Right the First Time

Software isn't "developed", it's constructed. Piano skills are developed
gradually with lessons. Software is constructed, like an office tower, at one
time based on a blueprint. Quality software starts with a quality blueprint.
Software blueprints are an art as much as a science. There is a beauty and
an elegance in simple designs. It takes a senior developer with years of
experience to draft simple extendable solutions to complex problems. Junior
developers are shorter sighted, becoming the authors of convoluted systems
with large maintenance costs.
The blueprint is a critical step but only half of the entire formula for
successful application creation. Even the right blueprint in the wrong hands
will never result in a quality product. Many may claim to be able to get the
job done, few pursue the path of Craftsmanship.
It is not just a matter of doing what is in the blueprint (the plan); it is about
achieving near perfection. In home construction, taking shortcuts leads to
squeaky floors and popping drywall plugs. In software creation, shortcuts

lead to poor application performance, excessive use of cellular data transfer,

bugs, and high cost of change.
A true craftsman will appear to cost more up front. The primary reason for
that is they are guaranteeing the solution will be done right the first time.
Craftsmanship results in a higher quality solution with a lower overall cost.
We follow the Unified Software Development Process, an industry leading
development

methodology with

proven

success.

This

process

was

originally developed by Rational Software, a think tank on how to build better

software.

Through a recent acquisition it is now owned and operated

by IBM. Because this isn't something we "just made up", our clients can
rest assured their project is in the hands of experts.

Time and Budgets are Important

Software is useless unless it solves a specific problem, within the budget and
by a specific time. Our experience and process allows us to accurately
predict the cost and schedule of your solution and stick to it.

Software Solves Problems

Software isn't written for software's sake. Software solves pain points within
an organization. If a feature cannot be directly traced back to benefiting a
user, it is dropped from the project.

Zero Maintenance
Solutions should be self administrating: by the users, for the users. The
developer should be able to easily remove his or herself from the daily
operation of the system with no impact.

Partner With, Not Work For

To understand the business problem that must be solved, we must
completely understand the business. We partner with our clients by learning
their business, how it runs, and designing seamless solutions that fit within
the greater context.

What is a Software Process

A software process, or methodology, defines the steps required to create
software successfully.
The Brief History of Software Process
Teams have been writing software since the 70's. Clearly time has brought
about many improvements in technology, language, and tools. While these
advances are exciting, the most important part of software construction is
"the how" not "with what".
In the late 80's, three engineers Dr. Ivar Jacobson, Grady Booch, and Dr.
James Rumbaugh each published a software development process. Each had
its own strengths and weaknesses. The software industry fell into several
camps, each holding to one of these methodologies as better than the other.
Grady Booch was a founding employee and chief scientist of Rational
Software. In the mid 90's Rational successfully negotiated the addition of Dr.
Jacobson and Dr. Rumbaugh. The three leaders, affectionately called "The
Three Amigos", were now under the same roof and working together. Their
collective intellect brought about two revolutions in software methodology.
The first was in 1997 when they published the Unified Modeling Language
(UML) specification. This was a combination and improvement upon their

previously disparate forms of diagram notation. Finally, a diagram could be

drawn and its intricacies immediately understood by software developers
across the world.
The second achievement was in 1998 when the Three Amigos published the
Unified

Software

Development

Process

(UP)

which

was

proprietarily

implemented as the Rational Unified Process (RUP) 5.0. This process

combined the best points of the three other processes into one cohesive
whole that could guide a project successfully from inception to completion.
It would take several years for the significance of these works to permeate
the industry. Even today many software teams are ignorant of these ground
breaking works.
Three Complimentary Methodologies
To the uninitiated, these methodologies look to be opposing. News
groups across the internet hold numerous debates on which method is better
than the others. The truth is that they are wonderfully complementary, each
addressing different aspects of the inherent difficulty constructing software.
Unified Software Development Process (UP)
There are four basic principles of the unified process: that software should
stress use cases (which show how it interacts with users), that the process is
architecture-centric, and that it is iterative and incremental. UP defines what
steps and artifacts (documents, diagrams) should be expected in the four
phases of a project:
1. Inception - Early analysis
2. Elaboration -- Detailed Analysis and Design
3. Construction -- Programming

4. Transition -- Deployment & Training

Extreme Programming (XP)
The three fundamental points of Kent Beck's Extreme Programming are: that
changes can be made to software both early and late in development with no
increase in workload, that code should be written in pairs so it is constantly
under peer review, and that software should be implemented as simply as
possible (no over engineering in anticipation of future uses)
Microsoft Solutions Framework (MSF)
Obviously Microsoft has been writing large scale software for over 20 years.
Hundreds of thousands of software developers are enlisted in their Microsoft
Developer Network in addition to their Certification programs. The latest
version of MSF provides a flexible framework for organizing a team, the roles,
and responsibilities throughout a project.
Summary
The customizable nature of these processes and their different focuses
allows them to be combined into a cohesive whole within an organization.

Nuway's Process
Nuway Software follows the Unified Software Development Process (UP). We
use UML to diagram and visually represent aspects of the system. Most
clients are unfamiliar with UML and we are very happy to educate them
before initiating the project.
Our proprietary NuDoc documentation technology allows us to communicate
efficiently throughout the project. This format was developed after years
of experience and client feedback. NuDoc eliminates the reading of out dated

documentation, confusion of what changes were made, and losing track of

feedback or notes.
The following synopsis outlines what our clients can expect as we work
together

on

the

project.

specific

road

map

is

provided

upon

commencement of a project.
Phase 1 Inception
During this phase, a good idea is developed into a vision of the end product
and the business case for the product is presented. Essentially, this phase
answers

the

following

questions:

What is the system primarily going to do for each of its major users?
What

could

an

architecture

for

that

system

look

like?

What is the plan and what will it costs to develop the product?
A simplified document that contains the most critical use cases answers the
first question. At this stage the architecture is tentative. It is typically just an
outline containing the most crucial subsystems. In this phase, the most
important risks are identified and prioritized, the elaboration phase is
planned in detail, and the whole project is roughly estimated.
Phase 2 Elaboration
During the elaboration phase, most of the product's use cases are specified
in detail. Most importantly, the system architecture is designed. The
architecture is expressed as several diagrams of the system, which together
represent the whole system. The analysis of the implementation model
includes components to prove that the architecture is executable. It is
imperative that the construction phase not begin until the architecture is
stable.
Phase 3 Construction

During the construction phase the product is built. During this phase of
development, the bulk of the required resources is expended. The
architecture of the system is stable, however, because the constructors may
discover better ways of structuring the system, they may suggest minor
architectural changes to the architects. At the end of this phase, the product
contains all the use cases that management and the customer agreed to
develop for this release.
Phase 4 Transition
This phase covers the period during which the product moves into beta
release (typically to a soft-release environment). A small number of
experienced users try the product and report defects and deficiencies.
Constructors then correct the reported problems. User documentation and
training are provided during this period.

About Craftsmanship
Nuway is committed to bringing craftsmanship and raising the bar in the
profession. Below we describe how we believe software should be written.
We unashamedly share our opinion of what is wrong within our industry.
However, criticism without care for solutions is of no more benefit than a
clanging gong or a crashing symbol: it's loud and annoying to everyone.
Many clients want to outsource a single project, but take over the support
and future changes when it is completed. In this case the quality of the code
and its ability to be easily understood by new people is of utmost
importance. A vendor who may be the cheapest up front may cost tens or
even hundreds of thousands of dollars later in wasted time and effort as the
receiving team tries to understand the code, or spends time replacing poorly
written parts.

What we mean by Craftsmanship

Craftsmanship is the fusion of attitude and competency.
Attitude is one's personal motivation to doing their best. Craftsmanship takes
effort. Craftsmanship requires discipline. The right attitude fuels the hard
climb necessary to learn improved ways of doing things. Some people want
to do well, but never put in the effort. In this case their actions betray their
true mind-set.
Competency is one's ability or skill in a field. Competency comes from many
paths: natural talent, education, trial and error, and experience over time.
Regardless of how it comes, competency is the extent of control someone
has on achieving their desired result. Someone may desperately want to play
Mozart on the piano, but if they haven't taken any lessons, the goal is simply
out of grasp.
The mark of a craftsman is someone with a wealth of experience,
demonstrated ability, and a strong desire to do better next time.
Why Craftsmanship Counts
Software construction is a continual process of choosing one way forward
from dozens (or hundreds) of possibilities. All of these choices stack and
ultimately become the finished product. A person with the right attitude will
evaluate many paths before deciding the best one. The first readily apparent
answer is often the wrong one. A person with high competency knows of
many more possible paths and which ones are dead ends.
The two major places where craftsmanship counts are performance and
extendibility.
Well crafted software runs fast. There is no "bloat" of useless processing or
unnecessary calculations. For instance, looking up information in a database

can be done once or require several round trips. The many round trips could
be 50x slower, but 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 effectively. Now poor craftsmanship is costing the
client money.
Well crafted code is easy to change and extend, even by 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 quick and
pleasurable experience to add additional functionality. If the code resembles
"spaghetti" it will take a long time to make the change and squash all the
resulting bugs. Now poor craftsmanship is costing the client money in
unnecessary effort.

The Right way to Write Code

Object Oriented Programming (OOP) through Design Patterns
Most, if not all, programming tasks can be boiled down to a generic problem.
It is likely these generic problems have already been solved. The solution to
a generic programming problem is called a Design Pattern. The use of design
patterns ensures you are solving a problem correctly, in a way that will scale,
and you won't run into unforeseen roadblocks in the future.
Self-Documenting Code
Nuway writes clean code. Code that self-documents as much as possible. In
practice this looks like:
1.

Routine names describe exactly what the routine does, with VerbNoun
naming convention.

2.

Each routine performs one well-defined task. If a routine does only one
thing, it's easy to find a problem or know where to make a change.

3.

Variable names are descriptive of the business value they contain, not
things like: var, val, i, j, etc.

4.

Special values are enumerated or stored as constants instead of

"magic numbers".
o

Size == PizzaSize.Large is clearer than Size == 12

Code Comments
When code isn't clear through self-documenting (see above), Nuway provides
the relevant comments. This is quality, not quantity. We abide by the
following principles when commenting:
1.

Clarify the intent of the code, don't explain what it does

2.

Whenever a decision is being made in the code, explain why

3.

Document any specialized knowledge.

If an external API requires calling two methods in a particular order to

work this must be captured for future reference when someone is doing
maintenance.

4.

Comment anything that gets around an error or an undocumented

feature in a language or environment
o If you've discovered a TCP listening routine doesn't handle exactly 1025
bytes, but all other values are fine, make a note of it

5.

If utilizing a Design Pattern, document which one it is and where it

came from (GOF, MSDN, Etc.)

Refactoring
Typically your first attempt at something is never your best. A second pass
will typically show better ways of accomplishing the same goal. Rewriting
your code a second time is called refactoring. This isn't something left to the
end "when I have time", it's part of the process. You refactor as you go. The
rules used in refactoring are extensive, but the reason Nuway practices it
are:
1.

Improves the design of software

2.

Makes software easier to understand

3.

Helps you find bugs

4.

Helps you program faster

Notation
Nuway follows the Microsoft standards for programming notation. The
purpose is to make the software code look as much like Microsoft's so you
don't have to switch mental gears as you read

1.

In C#, we use camel case notation

2.

In C++ we use Hungarian notation

Test Driven Design

The most expensive part of a software change is the verification the change
didn't break anything. This verification is called Regression Testing. Test
Driven Design eliminates the need for regression testing, thereby flattening
the cost of change.
The process was popularized by the agile development process eXtreme
Programming (XP). Test driven design means the programmers write
automated tests that check the code to make certain it is still correct. As the

team builds the total project, all the individual tests build up into an
extensive arsenal of tests that can very quickly guarantee the entire system
is operating correctly. This is critical to reducing the cost of changes in the
future. Now a change can be made, the automated tests run, and the
integrity of the system verified without copious amounts of manual labour.
Documentation
Following the UP generates a lot of working documentation. All this
documentation is in UML , the industry standard notation. Our documentation
includes:
1.

Use Case diagrams - to show stake holder ownership and system scope

2.

Activity Diagrams - to show complex business rule branching

3.

Class Diagrams - to show system design and interaction

4.

Sequence Diagrams - to show per use case message flow

Sources

1.

Erich Gamma, Richard Helms, Ralph Johnson, and John Vlissides,

Design Patterns: Elements of Reusable Object-Oriented Software, Addison
Wesley, 1995.

2.

Steve McConnell, Code Complete, Microsoft Press, 1993, 456.

3.

Steve McConnell, Code Complete, Microsoft Press, 1993, 488.

4.

Martin Fowler, Refactoring: Improving the Design of Existing Code,

Addison Wesley Longman, 1999.

5.

"Naming Guidelines", .NET Framework General Reference, MSDN, 2005.

6.

"Variable Names and Hungarian Notation", MSDN, 1998.

7.

Kent Beck, eXtreme Programming, Addison Wesley, 2000.

Nuway Guarantee
Our wealth of experience fused with industry standard best practices enables
us to unashamedly guarantee:

You will understand specifically what your responsibilities are as a

client and what Nuway will look after

You will only need to identify business needs, problems, and pain
points; we take care of the rest

You will know precisely when the project will complete, not a day later

You will know exactly what the project will cost, not a penny more

You will know the status of your project

You will see that you are in the hands of experts