Software development, what's different? - GoFuckYourself.com

Un4given · 05-18-2010, 02:23 PM

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......

sortie · 05-18-2010, 03:01 PM

Yeah, but you could have hired me and saved all that bullshit......so

LoveSandra · 05-18-2010, 05:11 PM

good reading

Un4given · 05-18-2010, 07:26 PM

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.

myjah · 05-19-2010, 05:50 AM

Thank you for contributing to the series with your personal experience and insight!

Un4given · 05-19-2010, 06:52 AM

Quote:

Originally Posted by BestXXXPorn

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.

BestXXXPorn · 05-19-2010, 06:59 AM

Oh thanks for copying that over!

avrevenue · 05-19-2010, 06:26 PM

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!

fatfoo · 05-19-2010, 06:46 PM

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.

Mickey_ · 05-21-2010, 05:27 AM

Quote:

Originally Posted by fatfoo

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.

P0rn0Gigi · 08-13-2010, 10:58 AM

where can i find some softweare codes examples for learning?

HarryMuff · 06-17-2011, 09:26 AM

It's great to hear advice from expert software engineers at GFY's adult "webmaster" board.

mukeshsnp · 07-09-2011, 02:41 AM

Thanks for writing it !

dc0ded · 07-20-2011, 03:27 AM

good job. very good article. very educational. hope you keep up the good job.

My Pimp · 09-10-2011, 02:47 PM

bump bump

possiblygreen · 10-06-2011, 12:43 PM

Brilliant post (posts?). Thank you!

jakejacksonxxx · 01-14-2012, 07:01 PM

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.

Bat_Man · 04-22-2012, 04:37 AM

Hey mate, Very good update ...
Cheers ...

realgirlsgonebad · 05-20-2012, 05:08 AM

very good mate, cheers

GFELIFE · 06-09-2012, 03:01 PM

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]

Bat_Man · 08-03-2012, 04:31 AM

Thanking for the all acknowledgement here.....all the caution will be helpful.....

Bat_Man · 08-21-2012, 07:36 PM

informative and helpful post....I shall book mark it.....good luck....

elclandestino · 09-15-2012, 01:47 PM

Sound advice, dude

Plenty of helpful shit to be found at programming-motherfucker[dot]net

silviustr · 12-12-2014, 01:44 AM

Great article!

bella.franceska · 12-12-2014, 01:44 AM

Thanks a lot man for all this killer post

miss.ralu · 12-12-2014, 02:29 AM

Interesting read, thankyou

parleal · 12-12-2014, 02:29 AM

Wow, this is fucking fantastic:D

fappingJack · 12-17-2014, 05:40 PM

Worth reading!

leila_mia · 12-20-2014, 05:56 PM

Thank you for your post.

opeedo · 12-21-2014, 11:43 PM

Yea.. this is cool

REDhorse · 02-11-2015, 03:15 AM

good job

j3rkules · 01-05-2016, 11:50 AM

Very interesting reading and thank you.

Slavic Porn · 12-01-2017, 07:08 PM

Nice article about software development. Thumbs Up!

05-18-2010, 02:23 PM	#1
Un4given Registered User Join Date: Jan 2008 Posts: 16	Software development, what's different? 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......

05-18-2010, 03:01 PM	#2
sortie Confirmed User Industry Role: Join Date: Mar 2007 Posts: 7,771	Yeah, but you could have hired me and saved all that bullshit......so __________________

05-19-2010, 05:50 AM	#5
myjah Back in the harbor Industry Role: Join Date: Sep 2003 Posts: 11,482	Thank you for contributing to the series with your personal experience and insight! __________________ VP of Marketing AVN Media Network Skype: AVNJill [email protected]

05-19-2010, 06:59 AM	#7
BestXXXPorn Confirmed User Join Date: Jun 2009 Location: Asheville, NC Posts: 2,277	Oh thanks for copying that over! __________________ ICQ: 258-202-811 \| Email: eric{at}bestxxxporn.com

05-19-2010, 06:26 PM	#8
avrevenue Confirmed User Industry Role: Join Date: Apr 2004 Posts: 1,881	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 High Quality Sites to Promote Official Twitter account Official Telegram account Skype: avrevenue Telegram: avrevenue

05-18-2010, 05:11 PM	#3
LoveSandra So Fucking Banned Join Date: Aug 2008 Location: Just Blow Me Posts: 10,551	good reading

05-18-2010, 07:26 PM	#4
Un4given Registered User 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.

05-19-2010, 06:46 PM	#9
fatfoo ICQ:649699063 Industry Role: Join Date: Mar 2003 Posts: 27,763	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: [email protected]

08-13-2010, 10:58 AM	#11
P0rn0Gigi Registered User Industry Role: Join Date: Aug 2010 Posts: 3	where can i find some softweare codes examples for learning?

06-17-2011, 09:26 AM	#12
HarryMuff Confirmed User Join Date: Dec 2005 Posts: 271	It's great to hear advice from expert software engineers at GFY's adult "webmaster" board.

07-09-2011, 02: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

07-20-2011, 03:27 AM	#14
dc0ded Confirmed User Industry Role: Join Date: May 2011 Location: Bedworth, United Kingdom Posts: 1,022	good job. very good article. very educational. hope you keep up the good job. __________________ Guaranteed Adult SEO Service- Just $275 per month

09-10-2011, 02:47 PM	#15
My Pimp Confirmed User Join Date: May 2003 Posts: 1,201	bump bump

10-06-2011, 12:43 PM	#16
possiblygreen Registered User Industry Role: Join Date: Sep 2011 Posts: 38	Brilliant post (posts?). Thank you!

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.

04-22-2012, 04:37 AM	#18
Bat_Man Confirmed User Industry Role: Join Date: Apr 2012 Posts: 421	Hey mate, Very good update ... Cheers ...

05-20-2012, 05:08 AM	#19
realgirlsgonebad Registered User Industry Role: Join Date: May 2012 Posts: 32	very good mate, cheers

06-09-2012, 03:01 PM	#20
GFELIFE Confirmed User 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!

08-03-2012, 04:31 AM	#21
Bat_Man Confirmed User 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

08-21-2012, 07:36 PM	#22
Bat_Man Confirmed User 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

09-15-2012, 01: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

12-12-2014, 01:44 AM	#24
silviustr Registered User Industry Role: Join Date: Dec 2014 Posts: 30	Great article!

12-12-2014, 01:44 AM	#25
bella.franceska Registered User Industry Role: Join Date: Dec 2014 Posts: 30	Thanks a lot man for all this killer post

12-12-2014, 02:29 AM	#26
miss.ralu Registered User Industry Role: Join Date: Dec 2014 Posts: 30	Interesting read, thankyou

12-12-2014, 02:29 AM	#27
parleal Registered User Industry Role: Join Date: Dec 2014 Posts: 30	Wow, this is fucking fantastic:D

12-17-2014, 05:40 PM	#28
fappingJack So Fucking Banned Industry Role: Join Date: Dec 2014 Location: somewhere down the road Posts: 2,172	Worth reading!

12-20-2014, 05:56 PM	#29
leila_mia Registered User Industry Role: Join Date: Dec 2014 Posts: 10	Thank you for your post.

12-21-2014, 11:43 PM	#30
opeedo Registered User Industry Role: Join Date: Dec 2014 Posts: 33	Yea.. this is cool

02-11-2015, 03:15 AM	#31
REDhorse So Fucking Banned Industry Role: Join Date: Feb 2015 Posts: 86	good job

01-05-2016, 11:50 AM	#32
j3rkules VIP Industry Role: Join Date: Jul 2013 Posts: 22,105	Very interesting reading and thank you. __________________ How To Build A Porn Site And Make Money \| My Best $$$ Cam Sponsor 3 Top Adult Hosting Providers

12-01-2017, 07:08 PM	#33
Slavic Porn Registered User Industry Role: Join Date: Jan 2015 Posts: 37	Nice article about software development. Thumbs Up!