We Can Do Better - apps4work/co.a4w GitHub Wiki

Thirty years ago, the State of The Art for the Software Development Life Cycle (SDLC) was 2 years between versions. It involved a series of consecutive processes, in what we called a "Water Fall", something like:

    • Requirements
    • Specifications
    • High-level design
    • Low-level design
    • Coding
    • Inspections
    • Unit Test
    • Function Test
    • Build
    • Packaging
    • System Test
    • Release

For example "Build" was performed by the Build Group, led by the Build Manager, and the process took perhaps a week in the schedule.

Today a programmer can open his Integrate Development Environment (IDE), create a new project, give it a name, choose a type, perhaps make a few choices, click the "Run" button, and he has a fully working product. It may not do much - it may only say "Hello World" - but all the paraphernalia for getting the product built happened automatically. And the word in Nerdville is that if it takes more than 15 seconds, you should get a new employer. (And the employer should know that if it takes more than 15 seconds, your programmer is now on Reddit or LinkedIn.).

The task of programming isn't concerned with that paraphernalia; it is concerned with adding value to the "Hello World" to make the project do something useful.

Product development life cycles for garments are measured in Quarters, several of them, sometimes more than 4. "Princess Michelle creates a new sensation with the dress she wears to the Royal Wedding; we'll have a dress like that in our store, in less than a year and half."

A high-end fashion website grabs the latest fashion from Paris and advertises to its customers, so that they can purchase a skirt, seen yesterday in Paris, for $1300, if they put 50% down and wait 6 to 12 months. "Yesterday's fashion, Next Year".

Everybody knows that in the future everything will be made by robots and computers and machines. Although about 80% of people are sure their job will be much the same in fifty years.

Skilled professionals in the Garment industry are firmly in that 80%. And they are just as wrong as most of the rest of the 80%.

There is no question whether new innovative software will break into the garment industry. The questions are when will it happen; which existing players, if any, will survive it; and, may be, whether any existing player will lead it.

We need an Integrated Dress/Design Environment in which the paraphenalia of the development process is taken care of by the software. In which the process of creating a dress is little more than giving it a name and choosing the type. Where the dress is always a complete garment - complete, for example, with construction information, - and always just one button click away from something that can be worn, on an avatar or a human, even if it starts only as the "Hello World" of dresses (like a shift dress). We need software that understands the semantics of the product being designed, so that it takes care of the human-mind-numbing details. We need human time to be consumed adding value to the product specification, and the associated elapsed time to be a choice we make in exchange for the value we get, not the unavoidable delay while we crank the wheels of an archaic process.

And just like the Programmer's IDE, the Integrated Dress/Design Environment isn't, and can't, be one monolithic program; it must be a set of programs working together, open to new function, and advancing with the needs of its users.