About designing for "change"...
-
venomation wrote:
It does mention that some people may find that idea "unprofessional"
The professional thing is to deliver what has been agreed upon with the customer. I'm not going to provide a plug-in architecture for something like a ping-command, nce it wouldn't add much value, merely luggage. Imagine the ping-command popping up each day when you start Windows, claiming that there are new updates to be installed :cool:
I are Troll :suss:
Eddy Vluggen wrote:
I'm not going to provide a plug-in architecture for something like a ping-command
While I tend to agree HERE, if as a developer/architect, you see an opportunity to design for expansion then why not do it? When you consider it really, even PING follows a basic 'command line' pattern: 1) Allows the user to select a command 2) Allows the user to provide basic command line args 3) Allows the user to get help explaining the user of the command 4) Allows the use of various command line options 5) ... so in a way, PING IS using a design pattern.
-
Eddy Vluggen wrote:
I'm not going to provide a plug-in architecture for something like a ping-command
While I tend to agree HERE, if as a developer/architect, you see an opportunity to design for expansion then why not do it? When you consider it really, even PING follows a basic 'command line' pattern: 1) Allows the user to select a command 2) Allows the user to provide basic command line args 3) Allows the user to get help explaining the user of the command 4) Allows the use of various command line options 5) ... so in a way, PING IS using a design pattern.
Ray Cassick wrote:
if as a developer/architect, you see an opportunity to design for expansion then why not do it?
I can see lots of opportunities to design for expansion, but my time is rather limited. If I can choose between building functionality that "might" be used "one day", and something that's needed now - I'll go for what's need now.
Ray Cassick wrote:
- Allows the user to select a command 2) Allows the user to provide basic command line args 3) Allows the user to get help explaining the user of the command 4) Allows the use of various command line options 5) ...
It's the command line environment that provides that functionality. It's strictly text, and as such, the ping-command does not offer any extensions for a visual plugin to configure it.
venomation wrote:
should be built for what the requirements currently do and not to make them for future changes unless required!
That's the current UI, and the ping-command does indeed provide switches. It does not provide it's own scripting-language, it's not prepared to output HTML, it does merely what it's intended for, in the environment it was designed for. You don't always take extensibility in account, just like we don't always take globalization in account.
I are Troll :suss:
-
Ray Cassick wrote:
if as a developer/architect, you see an opportunity to design for expansion then why not do it?
I can see lots of opportunities to design for expansion, but my time is rather limited. If I can choose between building functionality that "might" be used "one day", and something that's needed now - I'll go for what's need now.
Ray Cassick wrote:
- Allows the user to select a command 2) Allows the user to provide basic command line args 3) Allows the user to get help explaining the user of the command 4) Allows the use of various command line options 5) ...
It's the command line environment that provides that functionality. It's strictly text, and as such, the ping-command does not offer any extensions for a visual plugin to configure it.
venomation wrote:
should be built for what the requirements currently do and not to make them for future changes unless required!
That's the current UI, and the ping-command does indeed provide switches. It does not provide it's own scripting-language, it's not prepared to output HTML, it does merely what it's intended for, in the environment it was designed for. You don't always take extensibility in account, just like we don't always take globalization in account.
I are Troll :suss:
Then perhaps we have a different definition of 'extensibility' and a different vision of how the process 'should' work vs. how it 'does' work.
Eddy Vluggen wrote:
It's the command line environment that provides that functionality. It's strictly text, and as such, the ping-command does not offer any extensions for a visual plug-in to configure it.
Actually, given the way PING (as well as just about every other command line driven tool on windows) was written, you CAN wrap a visual component around it if you wanted to now. It is even fairly easy to use the /? options (provided that the original developer stuck to the standard) and have your GUI adapt to 'newer' versions of what it is driving with little work. I am not trying to say you are wrong here, and I know that we have all fallen into the 'just get it done trap' before, and I am sure at some point been bitten by it also. Now, globalization is a different story :) That's freakin' hard :)
-
I have been reading "The Art of Agile Development" and it says that design of software should be minimal but not entirely suitable for change. That instead, classes and such should be built for what the requirements currently do and not to make them for future changes unless required! It does mention that some people may find that idea "unprofessional" such as my self but it does have a point that "In the end your architecture will reflect change suitable for the requirements you need not what you *could* need".... Whats your ideas on this? Thanks :-D
I wonder if this is something like designing a system and have it based on 1 currency, you know there are multiple currencies out there, you know that retro fitting for multi currency is going to be a PITA, you know that it is relatively simple to add in the support for multi currency from the start of the design. And yet you do not add the 3 fields needed to support multi currency. Now that I call "unprofessional" and yep I've seen it done more than once.
Never underestimate the power of human stupidity RAH
-
I wonder if this is something like designing a system and have it based on 1 currency, you know there are multiple currencies out there, you know that retro fitting for multi currency is going to be a PITA, you know that it is relatively simple to add in the support for multi currency from the start of the design. And yet you do not add the 3 fields needed to support multi currency. Now that I call "unprofessional" and yep I've seen it done more than once.
Never underestimate the power of human stupidity RAH
This is quite a good example. The key thing is to know when to allow for future requirements, and when to concentrate on building what you need now. That's a judgement call that you learn through experience. Not every system needs to be multi-currency, but some do, so you need to make a decision about the system you are building. Many people quote the agile mantra "you ain't gonna need it" when in fact it's just a cover for "I can't be bothered". Other people get caught up in the "what if..." game and end up building enormously complicated frameworks to cover every possible imaginable requirement that any hypothetical future user might possibly want.
-
This is quite a good example. The key thing is to know when to allow for future requirements, and when to concentrate on building what you need now. That's a judgement call that you learn through experience. Not every system needs to be multi-currency, but some do, so you need to make a decision about the system you are building. Many people quote the agile mantra "you ain't gonna need it" when in fact it's just a cover for "I can't be bothered". Other people get caught up in the "what if..." game and end up building enormously complicated frameworks to cover every possible imaginable requirement that any hypothetical future user might possibly want.
David Skelly wrote:
what if
One of my BAs is a classic one of these, I caught her the other day what iffing we got some type of data and asked her if there was any indication that such a thing could happen. Then spat the dummy when she said not that she could see but it might happen.
Never underestimate the power of human stupidity RAH
-
David Skelly wrote:
what if
One of my BAs is a classic one of these, I caught her the other day what iffing we got some type of data and asked her if there was any indication that such a thing could happen. Then spat the dummy when she said not that she could see but it might happen.
Never underestimate the power of human stupidity RAH
Thanks for the comments ! I have decided to just use my "intuition" and try not to over design ! :-D
-
Then perhaps we have a different definition of 'extensibility' and a different vision of how the process 'should' work vs. how it 'does' work.
Eddy Vluggen wrote:
It's the command line environment that provides that functionality. It's strictly text, and as such, the ping-command does not offer any extensions for a visual plug-in to configure it.
Actually, given the way PING (as well as just about every other command line driven tool on windows) was written, you CAN wrap a visual component around it if you wanted to now. It is even fairly easy to use the /? options (provided that the original developer stuck to the standard) and have your GUI adapt to 'newer' versions of what it is driving with little work. I am not trying to say you are wrong here, and I know that we have all fallen into the 'just get it done trap' before, and I am sure at some point been bitten by it also. Now, globalization is a different story :) That's freakin' hard :)
Ray Cassick wrote:
Then perhaps we have a different definition of 'extensibility'
Guess so, and I started with a bad example on top of that. I take the parameters to a console application as part of the UI, just as a button on a form. To quote the topicstarter;
it says that design of software should be minimal but not entirely suitable for change.
Yes, a parameter might be required, but you're not going to prepare additional interfaces based on the idea that you "might" need them. One day. Somewhere.
Ray Cassick wrote:
Actually, given the way PING (as well as just about every other command line driven tool on windows) was written, you CAN wrap a visual component around it if you wanted to now.
Has been done a thousand times at least, since the invention of VB4. How often did you download or use such a visual ping? Does it add value? Or does it merely eat your time?
Ray Cassick wrote:
I am not trying to say you are wrong here, and I know that we have all fallen into the 'just get it done trap' before, and I am sure at some point been bitten by it also.
Yes, and thanks for the reminder. You're right; it shouldn't be used as an argument to get the product out the door. "Add a column there, we'll add the other three in the next version."
I are Troll :suss:
-
I have been reading "The Art of Agile Development" and it says that design of software should be minimal but not entirely suitable for change. That instead, classes and such should be built for what the requirements currently do and not to make them for future changes unless required! It does mention that some people may find that idea "unprofessional" such as my self but it does have a point that "In the end your architecture will reflect change suitable for the requirements you need not what you *could* need".... Whats your ideas on this? Thanks :-D
venomation wrote:
says that design of software should be minimal but not entirely suitable for change.
Well...the project should be ready for some change. So this is confusing.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it. My latest tip/trick Visit the Hindi forum here.
-
I have been reading "The Art of Agile Development" and it says that design of software should be minimal but not entirely suitable for change. That instead, classes and such should be built for what the requirements currently do and not to make them for future changes unless required! It does mention that some people may find that idea "unprofessional" such as my self but it does have a point that "In the end your architecture will reflect change suitable for the requirements you need not what you *could* need".... Whats your ideas on this? Thanks :-D
My understanding of the YAGNI principle of Agile (You Ain't Gonna Need It), is that, as another post pointed out, what's needed now is much more valuable than what could be needed in the future. Forgive me, I can't remember who I'm paraphrasing here, but the best practical description of how to implement this I've heard is: Given your knowledge of the system, predict one or two things that are the most likely to change - while completing the actual requirements protect yourself from these changes through abstraction. When a requirement change happens (and, as we all know, it almost certainly will) protect yourself from that kind of change ever happening again in the future. A contrived example would be a web application where all your colours are hard-coded. Suddenly The-Guy-In-The-Office-Who-Thinks-He's-An-Artist comes up and asks you to change the blue component of the background by 1. Of course, that just throws out the harmony and balance of the design, and suddenly a whole new colour scheme is on your desk. This is when you build a system to allow colour schemes to come from a config file (also known as CSS). Do you see where I'm going? Wherever I read this advice, it was written a whole lot eloquently than I've just put it :)
-
I have been reading "The Art of Agile Development" and it says that design of software should be minimal but not entirely suitable for change. That instead, classes and such should be built for what the requirements currently do and not to make them for future changes unless required! It does mention that some people may find that idea "unprofessional" such as my self but it does have a point that "In the end your architecture will reflect change suitable for the requirements you need not what you *could* need".... Whats your ideas on this? Thanks :-D
Architecture should be extensible, code should be minimal. Having worked in senior development environments for many years, if a line of code is written, I assume it is for a reason. To spent time determining that the statement was not a requirement is expensive.
-
I have been reading "The Art of Agile Development" and it says that design of software should be minimal but not entirely suitable for change. That instead, classes and such should be built for what the requirements currently do and not to make them for future changes unless required! It does mention that some people may find that idea "unprofessional" such as my self but it does have a point that "In the end your architecture will reflect change suitable for the requirements you need not what you *could* need".... Whats your ideas on this? Thanks :-D
I would say that the book is correct on the assumption that the requirements analysis is of a suitably high standard to correctly ascertain 'future-proofing' requirements. By that, i mean: If you have spent enough effort in requirement analysis to be confident of where change is and is not a risk and to what degree change may occur and have subsequently included specific requirements for change 'suitability' then by all means code to these requirements alone. If, however, you have vague and ambiguous requirements that are unlikely to have considered future requirement changes, i would recommend erring on the side of caution and spending a bit of extra effort to make the design as flexible as possible But as someone else has pointed out, you deliver what you are contracted to deliver. As developers we have an obligation to advise on the best course of action when setting out requirements and, if we feel there is need to facilitate future changes, this should be pointed out tot he client. If the client can be persuaded then, effectively, the requirements have been updated and you are still following the book. If the client declines, well you did your best but its their (now informed) choice. That said, unless the client has stuck their oar in as to how the technical design should be, there is nothing to stop you 'choosing' to implement a somewhat 'future-proof' solution (in terms of code layout, don't go slapping in superfluous functionality) if it does not impact your budget/time constraints. In most cases designing code that facilitates change is synonymous with designing code that facilitates maintenance and is, therefore, good practice regardless of your change-supporting requirements