If your software project doesn't "get users" it will die, bottom line. Launching a software project into production sooner rather than later greatly increases the odds the project will "get users" and ultimately succeed.
You've seen it time and again in recent years. You start a new project. You have project specs and a strong desire to include a test suite with your project to prove correctness and efficiency. But along the way your project specs change, you don't launch on time, and you have a gazillion tests to update. Your hopes of actually "getting users" dwiddles daily as you cope with all the code and test code changes. What do you do?
Throw out your test suite and launch the project into production.
Having users actually use your software provides near 100% code coverage. Having your "test suite" run in production on real data means you do not waste time creating fake data in the form of fixtures or factories. Continuous integration is provided as a side effect of server uptime. You can confirm your test suite is being executed by examining server load.
STDD is super easy to setup. On Android there is ACRA.. force closes stop, stack trace emails start, simply beautiful. In Django it's DEBUG=True in settings.py.. user gets an oops sorry page, you get a stack trace email.
I got the idea for STDD from staring at an unread copy of "Ship It" I had purchased some time ago. I don't know what's in the book because like I mentioned, I've never bothered to read it. I'm much too busy rolling out new versions of my software projects to read a book! But the title made me think, what IS the fastest way to deliver software while still maintaining some sanity with managing coding errors? I realized the actual code could easily be considered a test suite, and since I have the test results: either it crashed or it didn't, I followed through with stack trace email implementation to close the loop.
Probability Of Success
I created these probabilities based on my experience. I've never worked on a large software project with a hand-coded test suite that actually launched into production. Meanwhile most every other project I've worked on, without a test suite, has launched.
P(L|T) = 0.01
P(L|¬T) = 0.99
The "probability" of an actual project "launch" seems greatly dependent on the amount of academic masturbation contributed to the project in the form of a "test suite".
If you have a project where specs change constantly, you should try STDD. It will greatly increase the probability your project will launch, "get users", and succeed.
(This is satire.)
|Customize New Linux Install|
|Cisco CCNA Study :: Home Lab Notes|
|PostgreSQL Backup Script|
|Generate new Factorio map|
|Install and setup snmpd on RedHat Enterprise Linux|
|Debug a Linux Kernel in QEMU|
|Install xfce4 on Debian|
|Console Blackjack in Perl|
|Game of Life in C++ using the SDL2|
|active-record (2) android (1) apache (1) apt (1) arcade (1) awk (2) backup (1) bash (2) bashrc (1) battleship (1) bdd (1) blackjack (12) book (1) books (1) build (1) c (2) c++ (2) cacti (1) calculator (1) capybara (1) ccna (1) cisco (1) clang (1) clang++ (1) console (5) cpp (2) crm (1) crystal (1) data (1) database (1) debian (7) diff (1) elixir (1) factorio (2) fedora (1) firewall (1) freebsd (1) g++ (1) game (4) games (1) gcc (1) gem (1) git (3) github (1) gmail (1) go-lang (3) google-chrome (1) haml (1) home (1) infix (1) ipv4 (1) irssi (1) kernel (4) lab (1) latin1 (1) life (1) linux (7) lottery (1) matrix (1) meta (1) microsoft (1) moarvm (1) model (1) module (1) mongodb (1) mp3s (1) mutt (1) nautical (1) nqp (1) object (1) oidentd (1) operator (1) orm (2) pairing (1) pair-programming (1) patch (1) perl (1) pigpen (1) postgresql (3) powerball (1) programming (1) psql (1) python (2) python3 (1) qemu (1) raku (16) raspberry-pi (1) raspberrypi (1) reactjs (2) readline (1) retropie (1) reversi (1) rhel (1) ruby (1) sdl2 (4) sed (1) selenium (1) selinux (1) snmpd (1) split (1) ssh (1) stack (1) subnet (1) systemd (1) template (1) test (1) testing (3) tictactoe (1) trace (1) typescript (2) ubuntu (2) utf8 (1) virus (1) war (1) xargs (1) xfce4 (1) xvfb (1) zef (1) zsh (1)|
Copyright © 2005 - 2021
GregDonald.com · Contact · EUGOR · Nautical War · CRM12
All Rights Reserved