The typical corporate "internal" application development cycle can be (and often is) a road into the deep reaches of hell - for both IT staff and the end users who are forced to use stupid, hard-to-use, useless software that took so long to build that it's totally irrelevant.
And yet, it continues to happen in company after company in application after application. Why?
I believe it's due to the archaic adherence to the waterfall method of development. What - you're asking yourself - is the waterfall method of development? In a nutshell - it's a process by which people who are really concerned about keeping their jobs can hide behind "implementation strategies" and "feasibility studies" and "systems analysis" for a couple of years before beginning a "technology review" and "requirements re-engineering" process before actually coding something.
It's one of the oldest methods - and is linear in fashion. This means that the outputs of one process become the inputs of the next. Here's the basic set of steps:
- Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.
- Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.
- Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.
- Implementation: The real code is written here.
- Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.
- Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.
- Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.
This is the process was created about the time, and is as about as efficient as, using slide rules and drafting tables to create a capsule to take humans to the moon.
Technology wasn't always "instant" or "good." People used to have to meet (and fly around the country) to make sure everyone was on the same page. There was no "speakerphone", no email, no cell phone, no fax machine, no PDF, no online collaboration tools, no Internet, no nothing.
Just elbow grease, manual labor, and dedicated IT folks who "knew better" than the "lowly" end-user.
The frightening thing is - most internal development at corporations (and even big ISVs) is the same. The developers are in their own development "silo" safely tucked away from those pesky "users." After all, they know what's best, what's cool - and what the user is bound to "just love" - right?
Wrong.
There are several keys to making the process work better - and it's not rocket science - it's common sense. Yes, there are tons of so-call "agile" development methologies and hundreds of books and sites dedicated to the "how" of the process (Scrum, Crystal Clear, Extreme Programming, Adaptive Software Development, Feature Driven Development, Dynamic Systems Development Method, etc.) - but there are key elements the are common within all of them:
Let the developers interact with end users and get end users to help in the QA process. You need to know what the people using the software (and their managers) need the software to do. While it's true that most end users just want to do their one piece of the puzzle and go home (known as the "tab-tab-enter" crowd) - most developers will actually over-engineer software to do things they think the end user wants to do - rather than what it actually has to do.
Keep it simple. This follows the above rule. 99 times out of 100 - the user just wants to do something simple. 99 times out of 100 developers want to do something "cool." Only 1 time in 100 do these objectives match. So, when in doubt - build it the most simple, basic way that will work according to the way the end user says they'll use it. Don't assume the developer "knows better" than the end user. They usually don't - and if they don't listen - the end user will be pissed and not use the software after it's done.
Use better tools. Java and .NET are powerful languages - they are also a bear to code - but provide a great desktop experience. Scripting languages (Python, PHP, Perl, Ruby, etc.) are lighter weight (and limited to the browser). RAD tools like Servoy give you the best of both worlds - and are easy to deploy to either a browser or the deskop.
Build it - and release it - NOW. Don't wait for the completion of the entire application ("alpha") to get the user's input. Build a screen, a section of the application, deploy it and get feedback. Change it - and then repeat. As you build - get the feedback. Don't stress out about "scope creep" - there will be things that the end user will come up with late in the game that are important to them, to the company - and quite possibly to the bottom line of the company. Use common sense. There will be a 2.0 - so you don't need to put everything in there but the kitchen sink in 1.0 - but make sure end users are happy (even thrilled!) about what will be initially released.
Let the users determine the feature set - not the developers. Developers are often not the end users of the application. Unless they are, do NOT let them determine what the features will be. Let the people who actually use the features be the judge. Keep in mind - users will usually change their mind - or ask for things may require some re-architecting of what was created initially - but remember - the goal isn't to "finish" the software - it's to create software that will help the end users be more efficient and help the business to be more nimble, and hopefully, more profitable.
Think I'm blowing smoke? Give it a try on a small project. Once you do - you'll never go back. That, I can promise.
No comments:
Post a Comment