JWColby
jwcolby at colbyconsulting.com
Tue May 8 07:53:04 CDT 2007
Shamil, On the whole I agree with you. I also believe however that the phrase "simplest possible solution, which satisfies current customers' needs and which is affordable by customers' finances..." is best interpreted through a developers perspective. Let me give you an example that I think fits here. I have a client that STARTED as a CALL CENTER for disability claims. I got involved with this company when their original call center software broke down due to an almost complete lack of normalization. All information about the policy, policy holder, claimant and claim were all in one big table. We all know that won't work well for long. I came in, analyzed the problem, recommended a fresh start, spent about 4 months normalizing the data (and rescuing the old data), and turned on a new system. I think that part is a requirement and has nothing to do with the discussion other than to point out that the first system (which was not mine) could be classified as "agile programming", i.e. it got them up and running well enough to afford to hire me to "do it the right way". My example of a bit more complex choice is this. The client is now moving into actually paying the claims as well. Un until this point the client simply processed the claim, validated it by collecting medical records, hiring detectives to spy on the claimant if fraud was suspected etc. Now they actually write the checks. Writing the checks involves a LOT of data transfer between mainframes and our database. When I started I used "agile" programming, literally hard coding solutions to get a file exporting data from our database to theirs. These hard coded solutions were a nightmare to write, and a nightmare to maintain. Ultimately, they "settle down" and just function but that process of getting them written and debugged was simply horrendous. BUT, that is the way I did it in order to "make it work NOW". The bigger problem is that for every new client that my client gets, I have to hand code a slew of these reports. In the background, between fires, I began developing a "table driven report spec", a two table system, where table 1 defines spec level stuff (name of the report, path the report is stored in, query supplying the data etc.) and table 2 defines field level stuff (name of the field in their spec, name of the field in my query (see table 1), position of the data in the fixed width line, width of the data in the fixed width line, pad character of that field, pad direction of that field etc. I implemented the solution with four classes, one to hold the fields data, one to hold the report data, one to assemble the strings from the fields for the report, and one to do whatever "glue" was required for that specific report (generally tiny and manageable now). My point here is that the "hard coded" solution I used originally works. Once it is stable it works forever. However it is a ROYAL PITA to set up and get functioning. My table driven method OTOH is dead simple to get functioning. Write the queries to pull the data specific to a report, build two records in the report table and the field table. In many cases that is it. Push the button and go. If the formatting changes, you go into the table and change the pad direction, the pad character, the format string applied to the data, the position or width in the table etc. So which is Agile programming? They BOTH are. Agile programming is my first reports, hard coded, a PITA to get functioning but stable once they work. Agile programming is ALSO going back and developing a system to do these reports "push button". In the beginning "get it working NOW" was the requirement. In the end "get it PUSHBUTTON" was the requirement. The client never asked for the second method, I just built it and delivered it. However now when they need a new report I just build a query and fill in the tables. AND, equally importantly, it is a common set of code doing it. The maintenance is incredibly smaller. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil Salakhetdinov Sent: Tuesday, May 08, 2007 6:01 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Lazy,or Agile: that is the question... - Was Re:When to UseaJunctionTable Hi Gustav, I think we are still talking about different things: the key point of agile in my opinion is to be always prepared to *any* change customers may wish to implement in working deployed software. To *any* change not to *expected* (by developer) change. The more complicated modern software and database models and their implementations become the less chances a developer has "to be a little ahead of the client". Such being ahead just becomes impossible - read very expensive both in time and money. One partial solution of this issue are all kinds of application frameworks and generic tunable vertical and horizontal markets solutions - ERP, CRM systems etc. They are often all the customer needs but these solutions are usually expensive for small businesses or are not flexible enough, "heavy"... Another solution is agile "lazy" development with its maxim to implement the simplest possible solution, which satisfies current customers' needs and which is affordable by customers' finances... And experienced agile development practioner knows how to evolve such minimalist "simple and lazy" solution into more complicated one while refactoring it according to the change requests coming from customers as they are getting more and more experience with this deployed "simplistic" solution... Modern agile solutions differ from past traditional (and even incremental and iterative) way developed software grown from (phased) prototypes by clean streamlined coding, clear software architecture, full acceptance and as full as needed unit test coverage... - all that together with agile development principles quoted here by Eric in another message make agile solution promptly ready for any future changes not only for expected ones. And without additional efforts to foresee these future changes. One can say that there is no miracles and "free cheese" in this world - yes, I agree. Where then agile gets time/resources to develop software code and structures "ready for any future changes"? This "additional" time and resources come from proven well organized automated agile software development process. (Many good enough agile software development process automation tools are free.) One of the "side effects: of this well organized process is that agile developers are spending a way less time in debug mode. And everybody knows that debugging/fixing bugs may take 80% of software development (I mean its coding part) and that debugging is one of the toughest, less predictable and most "unattractive" activities of software development. Is here anybody who likes to spend hours in debugging mode? I doubts that (I can be wrong). Yes, creating child table takes a little but we are talking here not about this simple case but about the difference of agile development and traditional "right" development: Agile is ready to embrace *any* future changes and it handles these changes with courage and fun, "right" development is trying to foresee future changes - it often wastes resources by over engineering, it's followed by "hatred and fear" of future changes because its attempts to foresee these future changes often fail... Gustav, I "have been there seen that" - I mean "right" development. And as I noted before I'm still there in many projects but I'm also doing (trying to do) other projects using (part of) agile approaches - and I see how well they work - how they result in fun and courage and how they wash out "fear and hatred"... My postings in this thread is an exchange of ideas I currently explore to find all "pro" and "contra" and to elaborate my own approach but mainly based on agile principles for most of the future projects I will work on - I have no doubt that agile principles will rule in the near future software development.. Your turn now. Thanks you. -- Shamil