|
Thanks for response Eddy.
Eddy Vluggen wrote: How about a lot of small applications, calling them prototypes and have an intern make some nice OO code of it in their own pace?
The only problem is that I am somewhat of an intern lol  I guess I am trying to develop my skills in the right direction, rather than developing bad habits and having to break out of them late (which is always harder).
I will play around with some prototyping of smaller applications and maybe post some results of what I have acheived.
Dave
|
|
|
|
|
don't want to write code in code behind, since I have been reading it is hard to maintain, etc
Business logic and most of code is generally written in code behind. you must not refrain from it.
Is it ok to develop a large application all in code behind and then try to refactor it out later?
Refactoring costs high if not done properly and many times its tough decision in large projects.
'Refactoring: Improving the Design of Existing Code' by Martin Fowler
is a good book, you can refer.
|
|
|
|
|
Yes, it may not be as maintainable and extensible as you would like but the answer is Yes. When I asked for a peer review with the first team lead I ever worked for, a Russian, his response was "It works? it's good" Great advice. In fact if it works, it's great.
|
|
|
|
|
Have to disagree I'm afraid.
Software that 'works' is not good enough. Good software meets the following criteria
- Performs its function with minimal bugs
- Code Easy to understand by any average developer that may work on it in the future (if advanced techiniques are used that the average developer would not understand they should be commented to at least provide a jumping off point to learn that technique)
- Designed in such a way that changes to requirements can be applied with minimal impact (loose coupling)
- Designed in such a way that any single modification need only be made in a single location (DRY principle)
- Designed in such a way that any fairly generic bit of functionality can be re-used without too much hassle
- Exhibits reasonable performance in terms of speed and memory usage (according to requirements)
- Future proof to a fair degree (in terms of scalability and according to requirements)
and thats not to mention the little nuances such as naming conventions and comment styles
|
|
|
|
|
Hi Guys,
I am designing a Job Engine website for my developers. I have seen a lot of Job engine website in the net and ofcourse i know how the job engine works. But i have a point which worth to be discussed.
ofcouse there will be database for jobs adverts and job seekers profiles/cvs. where job seekers will search for jobs and apply.
Ok, The point that i would like to discuss here is: when the job seeker apply for a job. In real-life scenario, when a job seeker (John Smith) wants to apply for a job. he will send his cv to the employer. And again if the employer after some time advertise for another job. and the Job Seeker (John Smith) submitted his CV (but this time his profile/CV got update from last time).
The Employer, in this case will have two cvs for (John Smith). Old one and Updated one.
Now, comming back to our system design. the Job Seeker (John Smith) registered in the website and he created his profile and build his cv. of course he can update his profile/cv any time.
If we follow the above real-life scenario, by making the system copy the entire job seeker profile againest the job advert he is appying. we may end up with the following:
1. Put more weight on the database by creating multiple job seekers profiles.
2. The Employer may get confused by seeing an old job seeker profile. and when he search about the same job seeker (John Smith) in the job seekers database, he will see a different (updated) profile for the same job seeker.
Ok, the second scenario (which i am plannig to do) is: keeping a single profile for each job seeker and when a job seeker apply for a job.. we just link the job seeker profile with the job advert (no profile copy). but this way we will face the following:
1. Whenever a job seeker updated his profile it will get reflected in all the job advert responses. I mean, when an employer view the responses againest his job advert. he can see for exmple, application date, and job seeker name. and when he click on the job seeker name it just reading the job seeker profile from the database (the current). even if the job seeker applied before a year and before he updated his profile.
what i want from you guys, just your feed back and thoughts.
awaiting your replies.
Hussain Mohammed Saleh Attiya
ISP Technical Manager
Atyaf Telcom - Bahrain
|
|
|
|
|
Hi,
Unfortunatly, no body gives his thoughts or feedback. So, i am going to reply myself.
first of all, when a job seeker builds his/her CV he is always upgrading it during his career to make it more richer and professional.
noboddy will, downgrade his CV. Hince, in any case when the employer view the job seeker cv (the current one) which he submitted a year back and same cv he submitted now.. will not make any different for the employer.. the CV is always uptodate.
so, the system should be designed using the second way. which is keeping a single profile for the job seeker
Hussain Mohammed Saleh Attiya
ISP Technical Manager
Atyaf Telcom - Bahrain
|
|
|
|
|
You are obviously a child of today, no patience at all.
I think you have it wrong, try this scenario.
I am happy applying for 3-4 different types of contract, developer/architect, winforms developer, database, web (under duress) and shortly silverlight. Add in VB and/or C# and I may want 5+ CVs
Now I want a different CV emphasising different skill sets based on the type of contract I want to apply for. Also I have decades of development experience and can easily fill 10 pages simply by briefly listing the projects I have worked on. Most HR teams will choke on anything over 2 pages but some will want the lot so I offer a summary CV and a full project listing.
So in this instance I would retain all CVs, categorise them and allow the developer to indicate which CV to put forward for each contract. I would also have the functionality to replace a CV of x type with a new one.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Thanks Mycroft Holmes,
about having funtionality of creating professional CV containing projects, summary etc. it is already in the design plan.. but i did not mentioned.
we have also, customized a recruitment website for our client using a puchased source code from the following UK company
http://www.strategies.co.uk/products/job-board-software.asp[^]
that was classic asp we bought before 3 years. i dont know if they have the .Net version or not. Anyway,
those, guys also allowing job seeker to replace a CV when he is attempt to apply for a job. this will do the functionality of the differnet set of skills you mentioned.
in our application, we are trying to collect all the good features from the different jobs applications and also, we have to look the real-life HR scenarios.
thanks for your reply
Hussain Mohammed Saleh Attiya
ISP Technical Manager
Atyaf Telcom - Bahrain
|
|
|
|
|
Well doing what was suggested IS real life
It is always standard procedure (talk to a few people that help you locate jobs) to tailor your resume to a specific target, so many people have many multiple versions handy that highlight specific areas for specific reasons. A system that allows profiles to be built should account for that.
While it sounds like you are trying to consolidate ALL a persons information into one picture of a person that covers all their interests and experience, you may find that muddies the waters a bit when trying to do to searches and weighted matching.
|
|
|
|
|
Hi,
The system is already designed and almost going to be finish... from our experience with many clients when we set with the HR team and take all thier requirements. Yes, it is a standard procedures.
Job Seeker Register -> update his profile (his personal details, contacts and address) --> build his cv (using cv builder) or upload a document (CV).
when he attempt to apply he either apply with his current CV or upload new one.
this standard functionality is already taken into the account of the system. What i wanted is just to collect thouhgts and feedback. But i raise just one point which is:
when a job seeker update his CV using CV builder tool. Technically, he his editing the current record not keeping it as an old version CV and building a New CV from scratch (Adding new Record.). And whenever he want to apply with different cv he can do:
1. upload new cv when he attempt to apply for job (this is the easy way)
2. using cv builder to build a new cv (this will overwrite the existing one) then apply with his curent updated cv.
that was my point
bcz some of our client asked for copying the entire CV records againest the job and keep the orginal one unchanged. We are trying to come up with a general job application that fits most requirements.
the point i mentioned. i felt it is not right.
Hussain Mohammed Saleh Attiya
ISP Technical Manager
Atyaf Telcom - Bahrain
|
|
|
|
|
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 
|
|
|
|
|
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 
I are Troll 
|
|
|
|
|
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: 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) ...
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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 !
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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 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
|
|
|
|
|
I am planning to develop medium size library project for personal purpose. After documented the requirements, I designed an entity diagram. Now I am planning to define all classes, structs, enums and function body before coding the logic. As per my vision this method will help me to identify problems at the beginning, so that I can save the time to rewrite the logic. Is this a standard methodology? Is there any pre-defined method to do this?
Thanks and regards,
Thomas
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
