Quote:
|
Originally Posted by Dante Hicks
Does "enterprise level" mean anything, objectively speaking?
|
When i say enterprise level, im referring to things which generally follow whats known as the waterfall development method and are planned out in absolute detail before moving onto the next stage.
This is what ( im led to believe by lecturers ) is done in the upper echelons of enterprise development most of the time for large software development teams.
This has its drawbacks of course, the further along in the development cycle you are the more expensive it becomes ( in both time and resources ) to make changes to things previously done
When you do make a change, you have to go back to that point and redo the work
Customers are generally gits for this, they see what has been done and go "ooh wouldnt it be nice if..." or " i dont want that anymore..."
Thats what i guess the agile method was developed to guard against
In the agile method, generally speaking you do development in iterations. You start off with a few small tasks to do in each and go through the plan,implement,test,deploy,evaluate,(document?) cycle for each one of those iterations. At the end of each cycle the customer comes in and evaluates the progress, reprioritises the remaining tasks, adds new ones in / removes old ones which are no longer wanted and so on. They then sign off on the criteria for which the next cycle will have to pass, ie "the system shall be able to cope with invalid orders without crashing by creating an error message and moving onto the next order" or the like, And the cycle begins again. Some more tasks are chosen and planned,implemented,tested,deployed,evaluated etc etc
The theory is that the customer ends up getting precisely what they want, and its more forgiving of change then the traditional 'waterfall' approach however since you are only doing planning for specific tasks at any one time, there is no overall master plan when it comes to things like individual components on different iterations and how they are all supposed to interact together nicely. Its achieved through refactoring of old work and generally seems ( to me ) like a cludge/hack effort to make it work together.
It is also quite difficult to do agile development in monolithic teams, its best suited for smaller groups
Enterprise level development tends to favour the waterfall approach purely because of the masses of planning done beforehand ( and i guess because there are times you can have an unresponsive customer which does not help the agile approach much )
Quote:
|
Originally Posted by Dante Hicks
Again, speaking as an outsider (to the CS), I'm not sure it does. I write this posts minutes after receiving an email sent to all our company telling us our invoice processing system has just crashed and won't be restartable until tomorrow (it is the end of the financial year in a few days). It is a system responsible for a good proportion of our (non-staffing / financial) revenue accounting, perhaps about £6-7 million worth of orders. And it's crashed because there's more than a hundred invoices were processed on the same order, or something equally shit and pathetic.
Our capital projects (about £40m-£50m worth of expenditure I guess) are managed primarily through some badly linked excel files (which breaks every month when someone adds a new row into some file without telling anyone). This is the enterprise level a lot of the time.
The point I'm making is that lots of organisations making do with really shit software which (in the case of our invoice system) has undoubtedly gone through a full planning process. We'd have been better off developing something inhouse and at least being able to improve it as we went on. At the moment, all we can do is moan at the developers a lot.  |
Indeed, that sounds like your company had some real cowboys in there who failed to adequately test the system they sold you or even to plan for the event that something unexpected happens. What *should* happen is that such an order would fail gracefully without taking out the rest of the system - alas this appears to not be the case.
I would urge you to moan at management for choosing these developers in the first place and suggest that they look into replacing the system entirely with something developed more professionally and perhaps even in-house ( and with contractual obligations to have a certain level of reliability ). If the current system is costing you money that might light a fire under their arses to do something