Welcome to the GoFuckYourself.com - Adult Webmaster Forum forums.

You are currently viewing our boards as a guest which gives you limited access to view most discussions and access our other features. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is fast, simple and absolutely free so please, join our community today!

If you have any problems with the registration process or your account login, please contact us.

Post New Thread Reply

Register GFY Rules Calendar Mark Forums Read
Go Back   GoFuckYourself.com - Adult Webmaster Forum > >
Come here to learn from top industry professionals. SEO, Content Management, Automation, Marketing, and much more!

 
Thread Tools
Old 05-18-2010, 03:23 PM   #1
Un4given
Registered User
 
Un4given's Avatar
 
Join Date: Jan 2008
Posts: 16
GFY Educational Series: Software development, what's different? 1

Page 1 of 2

You are in charge of getting a new system developed and implemented.
You have met with all interested parties and outlined what the system
needs to do. A developer is hired and is given the plan. You feel
confident that all is well and your system will be a success
…will it?

Not so fast. Six months later the project is already late and over budget.
The developer who replaced the original one is working 12 hours a day
but the software never seems to get any closer to completion.
Part of the problem is the users say the software does not do what they
want and they keep asking for "must have" changes; also there is a ton
of bugs being found during tests. What went wrong?
Whatever it is your not alone.

The 2006 (Standish Group, 2008) indicates software projects generally
do not meet one or more of the cost (budget), time (schedule), or scope
requirements and only 35% of projects were successfully completed – while
19% of projects were failures, and the remaining 46% were considered
challenged. An outcome labeled as successful must meet all three of the
triple constraint parameters. A challenged outcome is one that that was
completed and operational but did not meet one or more of the triple constraint
parameters and a failed outcome is a project that was started,
but was canceled at some time during the development cycle.

An analysis of approximately 250 software projects between 1995 and 2004
showed an interesting pattern. When comparing projects that were successful
vs. those that ran late, were over budget, or were canceled without completion,
the primary reasons were related to poor project management practices rather
than any other factors (Capers Jones, 2004).

In contrast, things look very different in the engineering and
construction industry. According to the Engineering News-Record,
94 percent of the project customers they queried were satisfied
with the results of their projects, which suggests that construction
projects have much lower failure rates than software projects.

NOTE: These numbers are from older reports because they were freely available.


Over my Information Systems career, I have always wondered why software
development is so different from say building a bridge. After all,
if the bridges had a failure rate of 19% and 46% were questionable
people would stick to ferries. Could it be that the level of education,
and training of IT professionals is lacking? As a rule do persons in this
field make more mistakes than the rest of the population? Are consumers of
these products more naive than most? If the primary reason for failure is
project management then why? Again, are the people involved somehow less
motivated, educated, or talented than project management teams who build bridges?

As it turns out it is not people, but the product itself. Building software is
different than building bridges or cars or houses. It cannot easily be build
using the traditional methods of project management. The following summaries
point out how software and the process of building software are unique and
different. Hopefully once you are aware of them, your next software project
will be a success.

Software is Intricate

Even a modest program can consist of thousands of lines of code. But the
number of lines only begins to tell how complex a program is. There are
many sets of instructions in a program and these instructions interact with
other instructions to accomplish tasks. There are various inputs and outputs
to and from varying devices and third party systems. Errors must be anticipated
and handled to prevent incorrect results or system failure.

Computer programs are the most intricate, delicately balanced and
finely interwoven of all the products of human industry to date. They
are machines with far more moving parts than any engine: the parts
don't wear out, but they interact and rub up against one another in
ways the programmers themselves cannot predict. [Gleik 1992]


Software is Intangible

Software doesn't have height or width, it has no mass or volume, and you can't
perceive it as you would a bridge. When a bridge is being built you can see the
parts being put together, even before it is complete you can envision it. Software
is more spectral; it is the instructions for a group of behaviors. You might be
able to visualize individual behaviors but things tend to blur as you try to pan
out to large numbers of sequential and alternative behaviors.

The same things that make it hard to visualize software make it hard to
draw blueprints of that software. An architectural drawing of a bridge shows the most
minute details of the structure yet it most certainly is not a bridge. The architectural
drawing corresponds to the structure, but it's not the same as the structure.
Software, conversely, is just instructions for the behaviors that the
programmers and users want to happen. The blueprint and the program are one in the
same. Once the instructions has been completely written, then the software has
been created. Nothing else needs to be done. We have automatic tools that
convert this representation into a binary that the computer can execute.

This is an important realization: any architecture, design, or diagram we create for
software is essentially inadequate. If we represent every detail, then we're merely
duplicating the software in another form, and we're wasting our time and effort.

Requirements are Deficient

Rarely do the people who use the software have experience dealing with the abstraction
and complexity of software. They are the expert in the business processes the software
is being designed for and understand the main behaviors that are required, however they
cannot be expected to take into account all of the alternative flows and error conditions,
and how different sets of requirements relate to each other.As stated previously, accurate
requirements are only realized as the completed software.This means that any specification
of requirements for software is likely to be incomplete in important ways.

As the users start seeing the developed software it becomes clearer to them and they start
adding "essential change requests". They do this because they're just not able to
visualize a system of this complexity until it's at least partially complete.
Users and developers must work together throughout the development, refining the
requirements. Users need to revise the features based on their testing of the system
as it is being built.

Technology Changes Rapidly

Twenty years ago we were struggling with the MS-DOS operating system and
creating simple spreadsheets on our PCs. Today we edit video on our computers
and connect to systems across the world. Computers double in speed about
every two years, and this opens up more and more opportunities for software
developers. Software changes quickly—we all know that—but we may not be
aware of just how quickly it changes, and what impact this has on any new
software we try to build.

In contrast, we've been building bridges for thousands of years, ever since
the time of the ancient Roman and Chinese civilizations. The problem is well
understood, and the technologies change slowly. The first design for a bridge resembling
the modern suspension bridge was in 1595, and that basic technology is still what we use
today.

Continued in next post......
Un4given is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 05-18-2010, 04:01 PM   #2
sortie
Confirmed User
 
sortie's Avatar
 
Industry Role:
Join Date: Mar 2007
Posts: 7,775
Yeah, but you could have hired me and saved all that bullshit......so
__________________
sortie is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 05-18-2010, 06:11 PM   #3
LoveSandra
So Fucking Banned
 
Join Date: Aug 2008
Location: Just Blow Me
Posts: 10,551
good reading
LoveSandra is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 05-18-2010, 08:26 PM   #4
Un4given
Registered User
 
Un4given's Avatar
 
Join Date: Jan 2008
Posts: 16
Page 2 of 2

Best Practices Are Not Mature

Most programmers have had the experience of trying to modify a
system that works well, but in which it's virtually impossible to make changes
without breaking some of its functionality. Programmers call this fragile code.

Code becomes fragile when it's put together in an ad hoc fashion, without
enough attention being paid to its architecture. An architecture is the overall
structure and design of a system,. New technologies need new
architectures. For example, when Microsoft introduced "event-driven programming"
to BASIC in 1991 via its new Visual Basic development environment,
it provided powerful new capabilities, but also the potential for new
problems.

One of these problems was a poor design practice, which became so prevalent
that it ended up with a name of its own: the Magic Pushbutton. In eventdriven
programming, all a programmer does is write a few "event handlers,"
which are routines that respond to the user's actions. This technology means
that instead of having to write the core functionality for each new program
over and over again, a programmer can just add functionality to an application
skeleton that's provided for them

In the Magic Pushbutton, the only event handler that does any real work is
the one that's called when the user clicks the OK button. If the programmer
doesn't deliberately organize the program's code in a better way, then it all
accumulates in this one routine, which ends up as a huge, unmanageable blob
of code.

Technology Experience Is Incomplete

We've seen that software technologies change rapidly. New technologies
supplant older ones every few years, and even more frequently, new versions
of existing technology appear that radically change the functionality and
use of that technology. This change is necessary and inevitable.

Moreover, developers work with an enormous range of specialized third party
software components. Experience with these components can rarely be
carried over into future projects, because those future projects are unlikely to
use the same third-party components. Experience with enterprise application
frameworks is similar; these frameworks are so extensive that different projects
that use the same framework may well use totally different parts of it.

Whatever a developer was working on even three to four years ago is
unlikely to be of any direct use today. So what use is an experienced developer?
Is it true that every significant new piece of software is written by
developers who are essentially novices to the task?

It's true that long lists of desired technology skills, which are so prevalent
in IT job advertisements, are virtually useless. The bulk of the technical
knowledge required for a project will normally be learned on the job. However,
the "softer" skills that make one a good developer, or even a good team leader
or architect, do apply from one project to the next, and can accumulate over
time. These skills include the software development best practices. Sadly,
these skills are rarely mentioned in job ads.

Software Development Is Research

As noted in previous points, the requirements for a piece of software will
invariably be incomplete. There will be conceptual gaps that must be filled,
and there will be assumptions that aren't justified and aspects that just won't
work. Because clients aren't software experts, they won't always be able to
distinguish between what's possible and what's not, or know what trade-offs
are available. They need to work with the developers to discover this.

This means that the development process is a process of discovery—
progressively finding out the exact character of the software that will meet the
customer's needs. Developers must combine analytical and creative skills to
find out what their customer really wants (even if the customer's description
is confused and incomplete) and invent ways to combine these requirements
into a system that's logically consistent and easy to use.

We can't take it for granted that a given software tool or component will
work as we expect it to, or do everything that we need when we use it to create
our software. Even if the product chosen is mature and well regarded, and
even if the developers have used it before, because of the complexity of software,
you can rarely be sure that it can be used for the functions and circumstances
that are unique to a particular project. You can't tell if it will do the job
until you've actually made it do the job, and have seen that it works.

So software development is also a process of discovering whether and how
the chosen technology can be made to perform the role that's required of it.
Sometimes it will work as expected. Sometimes it won't, but there's a workaround
that takes more effort than originally planned. And sometimes the
technology just can't do what's needed. Software projects rarely run smoothly
from beginning to end. They frequently encounter setbacks and dead ends,
simply because of the scope of the unknown. In a very real sense software
projects are simply the process of discovering the unknowns: once the
unknowns are known, then the project is effectively at an end.

Construction Is Actually Design

Bridge building consists of a sequence of well-defined phases. The first step is
to perform the planning and design, which results in a set of plans and blueprints
that can be signed off. Once these tasks are completed, then construction
can start. The construction phase largely consists of well-defined,
repetitive tasks that can be accomplished by less highly skilled workers.

In contrast, software development is a process of research, so at no point
can definitive plans be drawn up. The more definitive you try to make the
plans, the more flawed they'll be, and the more labor there will be in revising
them to meet changing circumstances. As the shape of the software becomes
increasingly clear over the course of a project, the design of that software must
be revised again and again

If tasks can't be well defined, then we can't cleanly separate the design
and construction phases. Indeed, there's no construction as such; there's only
design on smaller and smaller scales.

Programming is more than just writing code. Each step requires the developer
to analyze some portion of the problem and design some aspect of the
solution.

Change Is Considered Easy

Last-minute changes to requirements are rare in bridge building because the
consequences are so severe. If you discover during the course of a project that
the foundations are in the wrong place, then it takes considerable effort to dig
them out and rebuild them in another place. This is obvious to clients and
contractors alike.

Compare this to software. Software is soft, by definition. Any part of it can
be changed at any time, just by rewriting that portion of the code. We expect
that bugs can and will be fixed wherever they appear in the system, as indeed
they are. Anyone who has written macros for Microsoft Office, or learned how
to write small programs at school or at a university, knows how flexible software
is and how quickly you can make substantial changes.

It's true that substantial changes can often be made quickly and easily, but
to properly implement them you really have to revise the architecture of the
software so that it gracefully supports the new functionality; otherwise you'll
just create a mess and make the software more fragile.

Change Is Inevitable

We've seen how software development is actually a process of design from
beginning to end. It includes design work to accommodate requirements
whose details become clearer as the project progresses, and design work to
reflect what's learned about the tools and components used to develop the
software. The process of software development is one of continuous design,
and therefore of continuous change.

Moreover, clients see how easily changes can be made, and expect that
they can change their minds at any point. Indeed, they often do, as they learn
more about what their budding software can achieve for them.

Change is inevitable, and if a piece of software isn't built to support change
then it will fall apart even as it is being built. The quality of software shows
itself when the software is first extended or modified. If the process of development
becomes one of extension and modification, then any software that
resists change will have a difficulties.

About the author


I have worked in Information Systems since 1995, including adult with
ExtremePaychecks and RageCash (2001 - 2006). As a consultant my goal is to
decrease the viscosity of the development process by discovering and
implementing new methodologies.
Un4given is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 05-19-2010, 06:50 AM   #5
myjah
Back in the harbor
 
Industry Role:
Join Date: Sep 2003
Posts: 11,235
Thank you for contributing to the series with your personal experience and insight!
__________________


Myjah@GFY.com
myjah is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 05-19-2010, 07:52 AM   #6
Un4given
Registered User
 
Un4given's Avatar
 
Join Date: Jan 2008
Posts: 16

Quote:
Originally Posted by BestXXXPorn View Post
No disrespect but I completely disagree with your assessment of software design being research. It should never be research... Many of the problems you've listed as being an "always prevalent issue" just simply aren't the case with solid developers and project managers that know how to scope a project correctly.

Everything you've written seems to assume there's this giant missing gap between the ones asking for a piece of software and the ones developing the piece of software. I've seen RFPs come through tighter than a frogs ass with wireframes already completed. They know what they want and they get exactly what they want delivered. It's also REALLY easy to cost those as everything is practically taken care of...

It is the lead developer's job to acquire all domain knowledge of a business and completely understand what the end goal of the software is before ever even writing a requirements doc (if a well done one isn't provided with the RFP). I have specialized in high end complex systems for the past 11 years. I've written four systems which have been multiple year projects. As a result, I don't have a big portfolio of sites but I'm very good at what I do...

The main problem arises when a client asks for an application to do x, y, z... If the dev company doesn't have someone that is experienced and really knows what they're doing, they're going to start building a system which does x, y, z. What they SHOULD be doing is the aforementioned; learn the business. When I build even a medium sized system I travel to the place of business. I sit down with someone from every level of the ORG and I start asking questions. I start with simple ones:

What do you expect this system to do?
What would make your job a HUNDRED times easier for you?

You would be amazed at how excited the whole company gets that they're getting a hand in "creating" this software that's going to make their lives easier. Then I'll sit and watch them work for a while performing their daily tasks that would interface with this proposed system. I tell them, "hey, now's your chance to vent about all the shit you hate about your current process". In the first 5 minutes you'll get to hear things you never would have thought to put in the system and learn ways to design the UI in such a manner that you're genuinely increasing their productivity. This understanding is CRUX to building a system which works best for the client.

After the first pass I go back and wire frame out the entire site. Then I go back to the business and show them around, get people's opinions, and make revisions if necessary.

Notice this is all the research part you talked about... but it certainly doesn't touch my dev team until ALL the research is done. You don't start coding until you know exactly what you're building. This process, for larger projects, can take well over a month, easy.

After it's all complete and has client approval I draft the requirements for the development team, lay the framework, and the coding begins. I've always delivered a product that has never needed revisions to core pieces of functionality or flow of information. There is no research involved during coding, only execution.


I can name 5 web development companies off the top of my head that I've had personal experience with that do things this way... None of them are in the adult space. The going rate for development in the adult space is a fraction of what these guys cost. There is a 1:1 correlation there ;) You get what you pay for. That's not to say there aren't plenty of main stream web development companies who don't do this and will charge the same price however :P

In a nutshell; the majority of issues you're describing are all communication problems and inexperienced developer/project manager problems. Perhaps because you're a consultant aiming to alleviate these exact problems? Was this an informative post or a sales pitch? I gather it's a little bit of both but some of the information is quite misleading IMO

PS: Post both parts together next time, makes it easier :P
This article is about what makes developing software different from other
forms of building. It does not propose solutions, which would come later
after discussing different methodologies and design principles.

That is when you beat your chest and make your sales pitch.
Un4given is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 05-19-2010, 07:59 AM   #7
BestXXXPorn
Confirmed User
 
BestXXXPorn's Avatar
 
Join Date: Jun 2009
Location: Asheville, NC
Posts: 2,278
Oh thanks for copying that over!
__________________
ICQ: 258-202-811 | Email: eric{at}bestxxxporn.com
BestXXXPorn is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 05-19-2010, 07:26 PM   #8
cici131421
Confirmed User
 
cici131421's Avatar
 
Industry Role:
Join Date: Apr 2004
Location: Asian land
Posts: 1,478
Very interesting article, Computer is a very young industry compare to build engineering. Im old age, houses and bridges were so well design as now!
__________________
AV Revenue Asian Niche Specialized Paysites that will convert your Asian traffic
VIP Revenue Brand new 100% HD Specialized Paysites
Payouts: Paxum, Payoneer, Check, Wire, ACH Debit Payments Available
wpXtube Free adult tube plugin for WordPress
cici131421 is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 05-19-2010, 07:46 PM   #9
fatfoo
ICQ:649699063
 
Industry Role:
Join Date: Mar 2003
Posts: 27,772
Interesting read. I agree that software is not a physical thing - you can't see it. You have to visualize it in your mind. Good luck.
__________________
Send me an email: postwriter123@hotmail.com
fatfoo is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 05-21-2010, 06:27 AM   #10
Mickey_
 
Mickey_'s Avatar
 
Industry Role:
Join Date: Nov 2005
Location: Worldwide
Posts: 3,256
Quote:
Originally Posted by fatfoo View Post
Interesting read. I agree that software is not a physical thing - you can't see it. You have to visualize it in your mind. Good luck.
__________________


LifeSelector Affiliates - Make money today promoting the online porn of tomorrow.

mb [at] lifeselector.com
skype: mickey-lcw
icq: 665-086
Mickey_ is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 08-13-2010, 11:58 AM   #11
P0rn0Gigi
Registered User
 
Industry Role:
Join Date: Aug 2010
Posts: 3
where can i find some softweare codes examples for learning?
P0rn0Gigi is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 06-17-2011, 10:26 AM   #12
HarryMuff
Confirmed User
 
HarryMuff's Avatar
 
Join Date: Dec 2005
Posts: 271
It's great to hear advice from expert software engineers at GFY's adult "webmaster" board.
HarryMuff is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 07-09-2011, 03:41 AM   #13
mukeshsnp
Registered User
 
Join Date: Nov 2006
Posts: 32
Thanks for writing it !
__________________
High Quality Fetish & Hardcore Asian Content
http://asianxcontent.com

admin (@) asianxcontent.com
mukeshsnp is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 07-20-2011, 04:27 AM   #14
dc0ded
Confirmed User
 
dc0ded's Avatar
 
Industry Role:
Join Date: May 2011
Location: Bedworth, United Kingdom
Posts: 1,021
good job. very good article. very educational. hope you keep up the good job.
__________________
Guaranteed Adult SEO Service- Just $275 per month
dc0ded is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 09-10-2011, 03:47 PM   #15
My Pimp
Confirmed User
 
Join Date: May 2003
Posts: 1,199
bump bump
My Pimp is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 10-06-2011, 01:43 PM   #16
possiblygreen
Registered User
 
possiblygreen's Avatar
 
Industry Role:
Join Date: Sep 2011
Posts: 38
Brilliant post (posts?). Thank you!
possiblygreen is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 01-14-2012, 07:01 PM   #17
jakejacksonxxx
Registered User
 
Industry Role:
Join Date: Jan 2012
Posts: 4
Awesome article, you've really identified a lot of what makes building software so much different than building most other things. Thanks for the project completion stats, they really put it into perspective.
jakejacksonxxx is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 04-22-2012, 05:37 AM   #18
Bat_Man
Confirmed User
 
Bat_Man's Avatar
 
Industry Role:
Join Date: Apr 2012
Posts: 421
Hey mate, Very good update ...
Cheers ...
Bat_Man is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 05-20-2012, 06:08 AM   #19
realgirlsgonebad
Registered User
 
realgirlsgonebad's Avatar
 
Industry Role:
Join Date: May 2012
Posts: 31
very good mate, cheers
realgirlsgonebad is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 06-09-2012, 04:01 PM   #20
GFELIFE
Confirmed User
 
GFELIFE's Avatar
 
Industry Role:
Join Date: Nov 2011
Posts: 131
gfelife is da best
You are in charge of getting a new system developed and implemented.
You have met with all interested parties and outlined what the system
needs to do. A developer is hired and is given the plan. You feel
confident that all is well and your system will be a success
…will it?

Not so fast. Six months later the project is already late and over budget.
The developer who replaced the original one is working 12 hours a day
but the software never seems to get any closer to completion.
Part of the problem is the users say the software does not do what they
want and they keep asking for "must have" changes; also there is a ton
of bugs being found during tests. What went wrong?
Whatever it is your not alone.

The 2006 (Standish Group, 2008) indicates software projects generally
do not meet one or more of the cost (budget), time (schedule), or scope
requirements and only 35% of projects were successfully completed – while
19% of projects were failures, and the remaining 46% were considered
challenged. An outcome labeled as successful must meet all three of the
triple constraint parameters. A challenged outcome is one that that was
completed and operational but did not meet one or more of the triple constraint
parameters and a failed outcome is a project that was started,
but was canceled at some time during the development cycle.

An analysis of approximately 250 software projects between 1995 and 2004
showed an interesting pattern. When comparing projects that were successful
vs. those that ran late, were over budget, or were canceled without completion,
the primary reasons were related to poor project management practices rather
than any other factors (Capers Jones, 2004).

In contrast, things look very different in the engineering and
construction industry. According to the Engineering News-Record,
94 percent of the project customers they queried were satisfied
with the results of their projects, which suggests that construction
projects have much lower failure rates than software projects.

NOTE: These numbers are from older reports because they were freely available.


Over my Information Systems career, I have always wondered why software
development is so different from say building a bridge. After all,
if the bridges had a failure rate of 19% and 46% were questionable
people would stick to ferries. Could it be that the level of education,
and training of IT professionals is lacking? As a rule do persons in this
field make more mistakes than the rest of the population? Are consumers of
these products more naive than most? If the primary reason for failure is
project management then why? Again, are the people involved somehow less
motivated, educated, or talented than project management teams who build bridges?

As it turns out it is not people, but the product itself. Building software is
different than building bridges or cars or houses. It cannot easily be build
using the traditional methods of project management. The following summaries
point out how software and the process of building software are unique and
different. Hopefully once you are aware of them, your next software project
will be a success.

Software is Intricate

Even a modest program can consist of thousands of lines of code. But the
number of lines only begins to tell how complex a program is. There are
many sets of instructions in a program and these instructions interact with
other instructions to accomplish tasks. There are various inputs and outputs
to and from varying devices and third party systems. Errors must be anticipated
and handled to prevent incorrect results or system failure.

Computer programs are the most intricate, delicately balanced and
finely interwoven of all the products of human industry to date. They
are machines with far more moving parts than any engine: the parts
don't wear out, but they interact and rub up against one another in
ways the programmers themselves cannot predict. [Gleik 1992]


Software is Intangible

Software doesn't have height or width, it has no mass or volume, and you can't
perceive it as you would a bridge. When a bridge is being built you can see the
parts being put together, even before it is complete you can envision it. Software
is more spectral; it is the instructions for a group of behaviors. You might be
able to visualize individual behaviors but things tend to blur as you try to pan
out to large numbers of sequential and alternative behaviors.

The same things that make it hard to visualize software make it hard to
draw blueprints of that software. An architectural drawing of a bridge shows the most
minute details of the structure yet it most certainly is not a bridge. The architectural
drawing corresponds to the structure, but it's not the same as the structure.
Software, conversely, is just instructions for the behaviors that the
programmers and users want to happen. The blueprint and the program are one in the
same. Once the instructions has been completely written, then the software has
been created. Nothing else needs to be done. We have automatic tools that
convert this representation into a binary that the computer can execute.

This is an important realization: any architecture, design, or diagram we create for
software is essentially inadequate. If we represent every detail, then we're merely
duplicating the software in another form, and we're wasting our time and effort.

Requirements are Deficient

Rarely do the people who use the software have experience dealing with the abstraction
and complexity of software. They are the expert in the business processes the software
is being designed for and understand the main behaviors that are required, however they
cannot be expected to take into account all of the alternative flows and error conditions,
and how different sets of requirements relate to each other.As stated previously, accurate
requirements are only realized as the completed software.This means that any specification
of requirements for software is likely to be incomplete in important ways.

As the users start seeing the developed software it becomes clearer to them and they start
adding "essential change requests". They do this because they're just not able to
visualize a system of this complexity until it's at least partially complete.
Users and developers must work together throughout the development, refining the
requirements. Users need to revise the features based on their testing of the system
as it is being built.

Technology Changes Rapidly

Twenty years ago we were struggling with the MS-DOS operating system and
creating simple spreadsheets on our PCs. Today we edit video on our computers
and connect to systems across the world. Computers double in speed about
every two years, and this opens up more and more opportunities for software
developers. Software changes quickly—we all know that—but we may not be
aware of just how quickly it changes, and what impact this has on any new
software we try to build.

In contrast, we've been building bridges for thousands of years, ever since
the time of the ancient Roman and Chinese civilizations. The problem is well
understood, and the technologies change slowly. The first design for a bridge resembling
the modern suspension bridge was in 1595, and that basic technology is still what we use
today.

Continued in next post......[/QUOTE]
__________________


The Full Girlfriend Experience! <--- Take a look at our site!
GFELIFE is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 08-03-2012, 05:31 AM   #21
Bat_Man
Confirmed User
 
Bat_Man's Avatar
 
Industry Role:
Join Date: Apr 2012
Posts: 421
Thanking for the all acknowledgement here.....all the caution will be helpful.....
__________________
Content lock your adult sites with BLAM ADS
Bat_Man is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 08-21-2012, 08:36 PM   #22
Bat_Man
Confirmed User
 
Bat_Man's Avatar
 
Industry Role:
Join Date: Apr 2012
Posts: 421
informative and helpful post....I shall book mark it.....good luck....
__________________
Content lock your adult sites with BLAM ADS
Bat_Man is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Old 09-15-2012, 02:47 PM   #23
elclandestino
Registered User
 
Industry Role:
Join Date: Sep 2012
Posts: 12
Sound advice, dude

Plenty of helpful shit to be found at programming-motherfucker[dot]net
elclandestino is offline   Share thread on Digg Share thread on Twitter Share thread on Reddit Share thread on Facebook Reply With Quote
Post New Thread Reply
Go Back   GoFuckYourself.com - Adult Webmaster Forum > >

Bookmarks
Thread Tools




©2000-, AVN Media Network Inc



Powered by vBulletin
Copyright © 2000- Jelsoft Enterprises Limited.