In the UK, soccer stats are copyrighted and tightly controlled; as the US appears to have more lawyers per head of the population than is strictly necessary, I'd imagine the same is true for NFL stats.
You don't want to end up getting sued for your fantasy league - get it legal if you can ! Oh, and prepare to sell some body parts to do it.
And it pays to experiment with what works for you. Trust me - university may seem like hard work, but it's the best place to learn about what works for you. FWIW - I don't think it's a free ride - concentration requires an act of will. You must decide to achieve a certain goal, and then use willpower - not medication, tricks, or gadgets - to achieve that goal; I just don't think there's a shortcut... I'd suggest you put together a plan based on the amazing amounts of feedback you've had already (and I would stick "get diagnosed with ADHD" way back on the list). Keep some kind of diary to see what works - it's easy to fool yourself that you're getting little extra done now that you've set an exercise regime, when in fact you're plowing through a lot more work. Google for "state of flow" - there's a fair amount of research into reaching a productive state. If you plan to work in software development, this is the one thing that will make or break your career - you can teach a monkey how to code in C, but only people who can concentrate for prolonged periods can create good software. This is a learnable skill, but it's potentially harder to learn than coding !
Licensing is tricky, and it fundamentally affects what you can and can not do later on - once it's Open Source, it's hard to go back. Here's what I'd do : hire a lawyer ! Work out why you want to go the Open Source route - it's morally good, and can make good business sense. But if you're building an application that is very specific to a particular industry, it may not make sense. For instance, if you're writing software to automate the day-to-day running of a law firm, you prob. won't get much community input; you say you have a framework (check out www.jcorporate.com for ways of dealing with the "framework/application" licensing issue), but how much of the framework is generically interesting ? As a business, Open Source is a very powerful way of getting traction with a piece of software. But you also have to feed it, keep the community happy, administer the rights of people to commit to CVS, ensure the project retains momentum - it's no free ride. And we really don't need another projet on sourceforge with a "pre-alpha 0.001 release" checked in 3 years ago, and a.plan file indicating world domination in 3 releases... Open Source is absolutely right if your project makes sense to the OS community, and if you can expect significant contributions from the community in return. Don't go Open Source because you feel you should to retain street cred. If you do decide to go OS, I'd suggest taking your code base, and take each source file - write the names on index cards - and split them into "Open", "Proprietary", "Not sure" (ideally with your sponsoring company). Hopefully, this process will help you decide where the boundary lies - it's a lot easier to decide when you're looking at concrete source files than discussing it in the abstract on slashdot... That should make sorting out the rest of the files fairly straightforward.
The key thing isn't technology - yes, maybe we can create a robot that can do "human" tasks in 50 or so years. The issue is economics - why create a McRobot to serve fries at a significant capital investment when you can hire someone for minimum wage ? Why build a housework bot when people are still so cheap ?
My prediction:
jobs that don't require face-to-face contact will get outsourced to the 3rd world, high-tech or low-tech (programming and sports-wear manufacture)
jobs which require significant skill but are essentially repetitive in nature (think factories) will increasingly be automated
many low-skilled jobs will remain too hard to automate economically - housework, food service, driving - there's prob. a fairly straightforward formula to predict the tipping point where automation becomes economically viable
The US job economy will gradually move away from the mega-corp employers - they will be hiring cheap labour in the 3rd world or automating - and increasingly towards small & medium size companies. Instead of a job for life at General Motors, people will have several gigs with small companies - some lasting years, some merely months.
Personally, I hope (and believe) that small companies can beat the big mega-corps, both economically (GM makes only a couple of hundred dollars on the 20K car, whereas a decent software shop will make a couple hundred dollars on a USD500 software package), and as places to work. The political clout will remain with the mego-corps - you need deep pockets on Capitol Hill - but it looks like political clout is becoming increasingly meaningless in the US... So, polarization is the name of the game. Good thing or bad thing ? I dunno, but I strongly believe it's going to be the way of the future....
for people who are passionate about it. For the "this looks like a good way to make a quick buck" brigade, I think the game is up...
Seriously, I've been through a couple of IT recessions, and it's never pretty. If you're good, care about your work and want to work hard, there are still plenty of opportunities. If you're into IT because it's well paid and involves no heavy lifting, you'll find it hard to get by untill the next boom (I've been through a couple of booms, as well). And in the confusion, lots of good people get laid off, and lots of clowns stay around - it's not fair, not clean and good people get screwed.
So, right now, IT is like most other jobs - if you're good, enjoy the work, and have people-skills, you'll probably be okay. If all you want is a fat paycheck in return for an MCSE, bad attitude and the ability to use TLAs without blushing, no, IT is pretty terrible right now...
RUP is a development process framework. It's sold as a bunch of documents/templates/intranet stuff, at a pretty eye-watering price. What's a development process framework ? It's a way of saying "when you start a software project, you usually need to go through a bunch of stages. For each of these stages, we have templates/guidelines/documents blah to help you build non-code artifacts (project plans, requirements documents, release notes, the whole kit & caboodle). Customize this to your organisation/project by choosing the stuff you need - out of the box, the process contains over 100 "artifacts", so you probably want to leave some out - and you will have all the tools you need other than an editor, compiler and caffeinated beverage vending machine to create world class software. If I were running a major software team for a large, sophisticated organisation with a lot of cash to spend, I'd definitely look for something like the RUP. It requires a significant investment of time, effort and money, but just deciding how you're going to build software is a cathartic process, and it flushes out all the views people hold explicitly, rather than finding out halfway through that Fred doesn't believe in source code control, and Sue only works from CRC cards. Check out "Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd Edition)" for a concrete example of how the RUP is applied - it's a lot more useful than the brochure-ware "books" I've seen.
If you are planning to create a new piece of software - hey, why not an operating system or something ? - and you don't expect to be in a position to actually sell anything for a few months, I'd stay away from the bureaucracy. Concentrate on the product, get it to a stage where you think you can sell it, and save your energy.
However, if you plan to run a consulting business, or plan to have people working alongside you, or plan to have frequent visitors - get an office. In the long run, if you can't afford to do the right thing now, you probably don't have the right backing to do this in the first place.
There have been a number of posts already, but I would create a simple spreadsheet breaking down all the risks you can think of as follows:
Risk category : eg. people risk (CTO gets hit by a bus), infrastructure risk (your server is destroyed by aliens), legal risk (you get sued by the RIAA for having an MP3 somewhere on your network), commercial risk (your biggest client goes bust), regulatory risk (the government licenses development shops) etc.
Risk impact: - the impact on the business if the risk were to occur. Probably best to summarize into 5 or so levels from "negligible" to "unrecoverable"
Likelihood - the chances of the risk occuring. Your office is unlikely to get hit by a meteorite, but your top coder may get headhunted and take all that knowledge with him.
You then have to reach a business decision how much to spend on mitigating each risk. Clearly it's worth spending time on "high likelihood, disastrous impact" risks, but you may not care much about a transport strike stopping the cleaning staff from getting into work for a couple of days. When you know which risks you care about, identify mitigation strategies. Typically, this starts with identifying an owner for the risk, who is in charge of the mitigation strategy. For instance, the development manager may have to find ways of mitigating the "top coder headhunted" risk by implementing code review processes, knowledge sharing systems, etc. You should not let the business view risk management as a technology issue - it's a business issue. Risk mitigation has associated costs, either financial, time, or opportunity cost - the best way to avoid not getting paid for your work is to avoid working for unreliable bill payers. If you come up with a wonderful risk list and proposals for mitigation, your work will be wasted unless the business is willing to bear the cost of implementing your proposals.
IT management is made up of many disciplines - some technical, some financial, some project-based, and some people-based.
I'm a development manager, and there are a handful of books which I think stand out in those disciplines, but I know of only 2 which cover my role specifically : "Leading a Software Development Team" by Richard Whitehead (which I have not yet read), and "Herding Cats: A Primer for Programmers Who Lead Programmers" by by J. Hank Rainwater, which I've started and looks pretty good. You could also try "The Manager Pool" - again, mostly about development teams - or "Software for your head".
I agree that "Peopleware" is an absolute must - it's focussed on managing development teams rather than system administrators or helpdesk staff, but a lot of the principles apply to pretty much any kind of team.
On the whole, though, I'd suggest you look for books related to the specific disciplines you are interested in, and grab some stuff from the general business literature shelf - "Finance for non-financial managers", and "Influence" have both helped me enormously !
If you fill your resume with words I can't be expected to understand, you can't expect me to make any kind of judgement about how you did that particular job. It also shows that you don't necessarily think about the audience of your communications - which implies to me that your communication skills may be poor.
By all means, if you are proud of what you have done, blow that particular trumpet. But blow it in a key I can understand - "I was the application designer on a project which improved the performance of our webservers by doing xyz; we used the following technologies to achieve this".
The reason I get turned off by a big list of skills an individual claims to have is because I have found that - without context - they are almost impossible to evaluate. I have seen CVs which contain nothing but buzzword bingo entries, all rated at "Expert level" - I don't know anyone who is "Expert" at more than a handful of disciplines. I'd have to be desperate to even see someone who just tells me they can code in java but offers absolutely no idea how they used this in their career. Remember, my objective is to find the CVs which offer the best chance of actually getting a hire, not to evaluate every candidate as a person. It's great to see a summary - "I'm an expert at X, I've done a lot of Y and Z, and I have experience in the following environments".
When I say "I like to see something unusual" I mean people who show some spark of individuality in their CV - I've hired people who are passionate pianists, who have worked as bricklayers before turning to IT, people who have worked oversees as volunteers, and I have tried very hard to get a team with someone from every continent - do you know how hard it is to find an antarctican ? It's been my experience that people who have other interests outside IT tend to be easier to work with - this is not universally true, it's a pretty solid heuristic.
Don't get me wrong - technical abilities are very important to me. But I nearly always prefer potential over experience, and it's very rare for me to hire someone who is technically excellent but hard to get along with. And that is why I look for resumes which are well written, show some contact with the world outside of the candidate's job, and generally gives the impression that the candidate is professional and communicates well.
The whole selection process is all about filtering out as many people as you can, as early as possible.
I once had to hire around 20 developers in a 6 month period, while managing the team through a pretty hairy crisis situation. The only way I could do that is by increasing the likelihood of getting a hire for every interview I did. To do that, I developed some heuristics:
reject CVs which list only "skills" and companies
reject CVs which use obscure jargon specific to the organisation or industry ("I was the lead AD for the MIPAC project, responsible for managing the annual fnjordflurgling process")
reject CVs which haven't been put together with care and attention to detail; anyone who claims to be "an excellent communicator" but submits a CV full of typos is prob. not aware of their own strengths and weaknesses.
Shortlist CVs from "interesting" candidates - people who have done something unusual, or who show some passion outside of work
Shortlist people who mention the business impact of the projects they worked on, or whose CV clearly shows how their projects fit into the bigger picture
Shortlist people who appear to have done their homework about the position and the company.
This process basically gives you 3 piles : rejects, shortlist, and maybes. I'd see the shortlisted folk immediately, and put the maybes through some pre-screening exercise rather than see every single one of them.
I don't particularly believe in psychometric testing when recruiting for technical positions - in fact, I think having a diverse set of characteristics in the team helps - but I would definitely ask people to sit a technical test before getting to see a "real" interviewer. I wouldn't be surprised if many organisations use psychometric tests to thin out the interview list even though most psychometric experts point out that this is not a particularly sensible way to act.
I don't know what the job market is like where you are, but in the UK it's pretty tight. You may have been in someone's "maybe" pile, and they just wanted to slim it down - it's not a personal slight, the company may not even be clueless, and if I were you, I'd concentrate on improving my CV to hit the "definite" pile.
if you phrase the issue in technical terms, you let the business folk off the hook. I have some experience with Peoplesoft, and it's hoodoo-ware - it's expensive to buy, it's typically sold at a senior executive level ("all your problems will be solved by our magical software ! Sure, it's expensive, but think about the benefits ! Oh, and if it doesn't quite work for you, you should change your business processes so they fit our software"), and it can be a little temperamental, so people who have it running tend not to like to mess with it.
By saying "there are sound technical reasons why not using HTTPS is a risk", you leave the debate at the technical level; most business folk I've met tend to think that they should not interfere in technical matters (and this is typically a view we techies like to reinforce). So they will leave it to the technical management team. And the technical managers will realize very quickly that they will gain nothing politically by jumping on this - the best they can hope for is that they don't break the application which cost the organisation a lot of time, money and political heartache.
If you phrase it as a business issue - not a black and white binary choice, but as a risk and cost issue. For instance, I would send a brief note to the head of HR (or the head of finance if you're also using it for accounting etc.), copied your boss and the head of IT, and explain that there is a risk that information managed by Peoplesoft being intercepted; that the information being intercepted may include usernames and passwords which allow unauthorised access to the application. Explain that the risk is not purely hypothetical, and offer to explain in more detail, but don't get into the specifics. You can then suggest which options are available; do nothing - the business may decide the risk is not worth the cost of the fix, implement HTTPS and deal with stability issues as they arise (explain that this may cause inconvenience to end users), or investigate further. You may even be able to get one of the Peoplesoft team to dig up documentation from the Peoplesoft extranet - it used to contain a lot of very specific implementation instructions, and the Professional Services team were not always up to speed with them.
Whether this is career-limiting is hard to tell; it depends on your organisation and specifically on your boss (and their boss). In my experience, Peoplesoft implementations are politically very sensitive because they nearly always coincide with business change, and that means there are going to be winners and losers. It's quite likely the IT management team don't want to hear the word Peoplesoft ever again. If you are worried about the politics, find someone you can talk to who is plugged into the politics - it may well be in your interest to keep quiet for a while, until the implementation settles down....
unlike eXtreme Programming, which is mainly about coding.
Scrum is all about managing the project, and in a way which matches the reality I perceive better than "traditional" models.
I've read the book in question, and I believe in Agile methods. One of the comments above says "methodologies are nowhere near as important as people" - check out the Agile Manifesto; line 1 says "we value individuals and interactions over processes and tools". Ken Schwaber (and Jeff Sutherland, who posted a reply here) are co-signatories.
The big problem I have found with Agile methods is that often the senior management team is unwilling to relinquish the impression of control over their projects. They insist on knowing everything up front - time, scope, budget - and even if they understand the empirical nature of software projects, that sense of control is very hard to give up.
I have found many of the "Top-down" implementations of Agile processes to be buzzword driven - the last thing you need to do Scrum is a new VP; the Scrum is intended to make the VP redundant ! I'm not surprised many people have had bad experiences with XP - the 12 practices are finely balanced, and distorting that balance (e.g. by over-emphasizing "the simplest thing that could possibly work") is a great way to ruin a project. Of course, I'm inclined to believe those organisations will struggle with any methodology; one thing Agile methodologies seem to do is draw out organisational weaknesses.
I'm working on a project right now where we have a very agressive schedule; we are pretty sure we can code the thing, but because our average corporate decision takes longer to reach than the project's timeline, we're hitting some rough spells. The cause is the decision making process; the effect is an unhappy project. In a "traditional" project, with analysts and project managers etc. and a sizeable up-front analysis phase, our corporate weakness would be less obvious; because we're saying "decide today, we'll have working code by the end of the week", our inability to decide is highlighted.
I'd recommend Ken's book; it's worth reading, and even if you don't agree with all he has to say, you might learn something.
It hints at a solution - iterative development, tests to show progress, frequent communication, and a release plan all feature in there - but it devotes too much time talking about tangential issues, and not enough really investigating these central issues.
The stuff which differentiates web projects - in my experience - is:
they tend to have very compressed schedules
they are usually very visual - stakeholders can usually see both their own site and a bazillion other sites on the web; a lot of requirements discussions seem to to go something like "make it like amazon when you see the homepage, and like dell when you buy something, but make it nice and light like google and...". This is pretty hard to capture in a requirements document...the visual nature of web projects tends to lead people to assume the underlying stuff is easy to understand too ("I know we're selling books, but if you just make it do auctions like ebay we could earn an additional bazillion dollars")
many of the techniques that help you develop solid code are not easy to adapt to web development, e.g. unit testing, automated system & regression testing, there are comparitively few design patterns catalogued (the "Core J2EE patterns" book is about the bestI've seen thus far, and that is platform-specific), etc.
A lot of web projects are exploratory in nature - both for the business and in the technology used. It's hard to build a solid code base from a prototype.
The shared risk issue is not really specific to the web - it's a common issue with consulting style contracts.
That's not what I thought was annoying - it was the very condescending tone this book takes towards the business folk.
At best, this is consultant mumbo jumbo - "just you leave all the difficult stuff to me, I have a brain the size of a planet and will prove it by saying the word "synergistic" a lot".
At worst, it's precisely why we techies tend to get a bad reputation in many businesses. Many business people may find it hard to express their knowledge in the terms that we techies like; much of what they do may be hard to encode in nice UML diagrams, but they do not deserve to be treated like idiots. And that is the distinct impression I got from this book - the authors seem to imply their knowledge is infinitely superior to that of their customers, even when it concerns the customer's own business.
If you read the review again, you should find I do not claim SQL is never embedded within web pages; I simply object to the many unsubstantiated, sweeping statements that litter this book, often left dangling with very little context.
the point is the sweeping statements that litter this book, often implying that Web XP (which after reading this book was still a pretty hazy concept to me) is the only solution. The quote in question is from a section about the team roles in Web XP projects - it is almost left dangling on its own - there's no discussion about the problem, and none about possible solutions.
Have I seen a lot of embedded SQL in my time ? Sure - I've even written some. Is Web XP the only cure for this evil ? Uh...no. In fact, does any process shield you from poor design or poor implementation ? Well, no, probably not.
Another quote that annoyed me : while talking about the quality of web site code, "Few developers used an object oriented approach to development. Most used procedural languages, which made refactoring code or making changes to it much more difficult". Well, I'm a bit of an object bigot, but I would contend that the key tension here is not OO versus procedural, but rather time versus quality. I've worked on code in procedural languages that was very easy to work with, and OO systems which were an unholy mess. The reason many web sites are brittle is not that they don't use the right inheritance tree, but rather that they are put together in a very short space of time, and with ever-changing requirements.
I don't think OSS is making a big dent in MS revenues - it's still virtually impossible to buy a new PC without windows pre-installed (and pre-licensed).
Instead, I think MS is suffering from a lack of innovation. There is simply no compelling reason for corporates to upgrade their software anymore - Windows 2K is fine for business use, they don't get anything in XP other than support problems. You might upgrade Office to be able to read other people's files, but there are precious few "must-have" features to differentiate the current offering from Office 97.
The most significant reason for users to upgrade in the recent past has been MS's change in licensing policy - signing up before the deadline gives "free" access to upgrades for a limited period. I know that many corporates bitterly resented this pressure. However, the next version of "Windows for Servers" keeps getting pushed back, and many corporates are only now upgrading their servers from NT4 to W2K - not to take advantage of new features, but because support is being withdrawn.
So, while OSS is undoubtedly snapping at MS's heels, providing a much-needed alternative and nibbling away at the revenues, the bigger problem is that historically, Microsoft have taken ideas developed elsewhere and "embraced and extended" them. Right now, there are precious few radically new ideas to embrace, and the only way for MS to continue to grow their revenue is to find new must-have features. In short, they need to innovate under their own power.
Kent Beck - co-author of JUnit - recently published "Test-Driven Development", a book about how you can change your coding habits by creating the tests up front.
One of the most useful sections is a complete walk-through of the creation of unit-testing tool for Python - it's probably the best way of understanding the internals of the JUnit framework without trying to reconstruct every single line of code...
A previous poster has already mentioned XP - personally, I think the idea of gtetting your customer to do acceptance tests is pretty powerful in this case.
If you have someone from your customer working alongside you, helping you make prioritisation decisions, seeing the progress you're making day after day, you stand a far better chance of having the schedule discussion in a fruitful way.
Most companies have been bitterly disappointed by development projects, and web projects seem to be particularly contentious. Most business folk aren't stupid - but they have been told so much bullsh*t by technical types that they are unlikely to believe you when you say "Trust me, I'm a professional, I alone have the magic mojo to know the future". They need to see first hand that you are someone who delivers (regular small deliveries are far better than a big release after months of frantic coding), who understands their business (user stories and the planning game establish your credibility) and who delivers quality solutions (unit testing and acceptance testing).
It sounds like your prospect has been burnt before - how did they end up with a front end but no back end ? - so the best thing you can do is establish credibility not through making statements about what is and is not possible, but by explaining your doubts and saying "I'm gonna take this job, on these conditions : 1. we look at the deal in a week, and both parties can walk away if we're not happy. 2, someone from your business comes to work with me as an acceptance tester and business guru. They tell me what is and is not important, and tell me when it's good enough". You should be able to make decent progress in a week (if your project allows, 2 weeks would be better...), and at the end your onsite customer will understand the realities of the situation. You can then look at the schedule again using "yesterday's weather" (the easiest way of estimating how quickly you're going to get through your work is to look at progress to date) as the measure of likely success. If you have worked hard, but completed too little of the project to be likely to finish on time, you have a leg to stand on.
The XP principle of building only what you need to get today's tasks done is esp. going to help you out - one problem of database design is that it's very easy to get tied up in beautifully elegant schema designs which almost, but not quite, work.
2 final points : invest in a bug tracker, even if it's a spreadsheet or card index. By using bugzilla or something similar, you can allow your customer to contribute bugs and see the bug list - and you won't forget to fix a little shortcut later. You also want to make sure you're going to get paid ideally in advance. When development projects go wrong (and let's face it, this one doesn't look too promising regardless of the collected wisdom of/.), suppliers usually end up not getting paid. You may not be able to afford to turn down the work, but can you afford to work without getting paid ?
There's a bunch of stuff I do when trying to remain productive but without the immediate inspiration.
- Refactor. Look at my work to date, and see if there are things I could improve without adding new features or changing the external behaviour. Refactoring steps should take a fairly short time - it usually takes me around 30 minutes to make a "normal" improvement. I often get a flash of inspiration during that time, so once I've finished the refactoring I have something new to move on to.
- I believe very strongly in using test driven design (there's a book by Kent Beck on the topic which I recommend). When I'm stuck, I like to create additional unit tests for functionality I know I'm going to be implementing in the next day or so. Doing so exposes new ideas and insights, usually enough to get me back to coding the business functionality. You could argue that test driven development is a very strong antidote for the malaise you describe because it forces you, the programmer, to create many micro-tasks (unit tests) and complete them several times every day.
- Browse the books that seem to inspire me to write better solutions : Design Patterns (Gamma, Helm, Vlissides, Johnson), Agile Software Development (Robert Martin). Usually I recognize something appropriate to my current project, and get inspired to improve it...
- Code reviews : get someone to review my code, review someone else's code. Fresh eyes, new ideas, the joy of communication....It's really easy to get bogged down in the detail of my current project. I like being able to look over the parapet and remind myself of the bigger picture, but in the most concrete way - by looking at the code.
Useful not just for Java mavens....
on
Effective Java
·
· Score: 1
I am an infrequent Java programmer, but I found this book extremely useful when thinking about design in other languages. Much of the advice about how to fashion reusable libraries, how to think of the users of your class as potential wrong-doers is extremely useful.
While most of the other posts have concentrated on the security aspects, the project management side of developing e-commerce sites is also a nightmare. Most projects I've worked on have caused either the customer to be unhappy because their (vague, unstated) expectations weren't met, or the supplier to be unhappy because their (inarticulate, overpriced) staff was working 80 hour weeks and they didn't get paid enough.
Developing in-house capability is hard - you need to have a bunch of expensive techies running around, someone to manage them and the client, and you get stuck with maintenance and support issues ("we're such a good client, could you not just change it for free ?").
I would look around for a local software development shop - ideally around the same size as you - and form a (more or less formal) partnership. If you have customers who want e-commerce capability, you bring the customer relationship, branding capabilities are and account management. The technical partner brings project management, technical skills and maintenance/support capacity.
That way, you are less likely to end up with unhappy customers - at least if you choose a decent partner - and you don't have to invest a lot of time, effort and money in an area you're not equiped to exceed in.
Read "eXtreme programming for web projects" to see some of the joy that awaits you - even if you do look for a partnership...
is iterative design. Which is becoming fairly widely accepted in OO circles, and almost universally accepted in Agile circles.
Databases, however, are a lot harder to iterate - the cost of change is higher than with any other code. Martin Fowler is laying down an approach to manage (not reduce - manage) that cost, and it all comes down to a guess we have to make - do we think the overall cost/benefit tradeoff of an iterative process is better than a Big Design Up Front process ?
On the eXtreme Programming mailing list, there's been a lot of discussion about how to deal with databases - some deny the need for databases altogether, some advocate using Mock Objects for testing and even development etc. It all boils down to the cost of change - it's expensive to change a database design because it is very hard to identify the knock-on effects. Some changes are relatively easy to manage - adding a column is unlikely to actually break anything - but others can wreak havoc with existing applications - changing the type or size of a column for instance.
I'd love to think that the next big improvement in software development tools is not going to be yet another language but a sensible way of tying objects to their persisted data. All the solutions I've seen so far are bolted-on - they either force the database into unnatural positions, or make the objects fit into a model that's not quite what they'd be otherwise.
In the meantime, this article is well worth investigating - the idea of evolving the datamodel in tandem with the migration scripts is very powerful.
Slashdot is not the place to ask this question. Even if you had given us enough information - which other posts have already told you is not the case - developers are notoriously bad at estimating the amount of time required to do anything. We tend to confuse "simple" with "quick". I can't count the number of times I've seen a task and thought "That looks easy - I already know how to do that - I'll give myself a bit of free time and say 2 days". Then I find myself a week later still hacking out "simple" code - there just turns out to be a lot of it.
The opposite is of course also true - I've frequently been asked to solve a problem and thought "wow - that's really hard to do in a clean way. I gotta take a couple of weeks just to figure out how to do it - better say a month" when there's a nasty hack that can be implemented in an afternoon.
So, what is the evil answer to your question ? Get some hapless consulting firms (3 should be enough) to quote for the work. They will force you to specify what it is you want in a lot more detail ( a useful exercise in its own right), and make up a number. Ask for their hourly rate and you should be able to come up with a decent idea.
You should also read Steve McConnel's "Rapid Development" - it is full of fairly scientific ways of estimating software projects (and it's pretty readable even for a non techy), and you could do should read Cockburn's "Agile Software Development" book for ideas about how to break out of the "but I have to know how much it's gonna cost before commiting" cycle.
Slashdot Mirror
In the UK, soccer stats are copyrighted and tightly controlled; as the US appears to have more lawyers per head of the population than is strictly necessary, I'd imagine the same is true for NFL stats.
You don't want to end up getting sued for your fantasy league - get it legal if you can ! Oh, and prepare to sell some body parts to do it.
And it pays to experiment with what works for you. Trust me - university may seem like hard work, but it's the best place to learn about what works for you. FWIW - I don't think it's a free ride - concentration requires an act of will. You must decide to achieve a certain goal, and then use willpower - not medication, tricks, or gadgets - to achieve that goal; I just don't think there's a shortcut...
I'd suggest you put together a plan based on the amazing amounts of feedback you've had already (and I would stick "get diagnosed with ADHD" way back on the list). Keep some kind of diary to see what works - it's easy to fool yourself that you're getting little extra done now that you've set an exercise regime, when in fact you're plowing through a lot more work.
Google for "state of flow" - there's a fair amount of research into reaching a productive state.
If you plan to work in software development, this is the one thing that will make or break your career - you can teach a monkey how to code in C, but only people who can concentrate for prolonged periods can create good software. This is a learnable skill, but it's potentially harder to learn than coding !
Good luck.
Licensing is tricky, and it fundamentally affects what you can and can not do later on - once it's Open Source, it's hard to go back. .plan file indicating world domination in 3 releases...
Here's what I'd do : hire a lawyer !
Work out why you want to go the Open Source route - it's morally good, and can make good business sense.
But if you're building an application that is very specific to a particular industry, it may not make sense. For instance, if you're writing software to automate the day-to-day running of a law firm, you prob. won't get much community input; you say you have a framework (check out www.jcorporate.com for ways of dealing with the "framework/application" licensing issue), but how much of the framework is generically interesting ?
As a business, Open Source is a very powerful way of getting traction with a piece of software. But you also have to feed it, keep the community happy, administer the rights of people to commit to CVS, ensure the project retains momentum - it's no free ride. And we really don't need another projet on sourceforge with a "pre-alpha 0.001 release" checked in 3 years ago, and a
Open Source is absolutely right if your project makes sense to the OS community, and if you can expect significant contributions from the community in return. Don't go Open Source because you feel you should to retain street cred.
If you do decide to go OS, I'd suggest taking your code base, and take each source file - write the names on index cards - and split them into "Open", "Proprietary", "Not sure" (ideally with your sponsoring company). Hopefully, this process will help you decide where the boundary lies - it's a lot easier to decide when you're looking at concrete source files than discussing it in the abstract on slashdot...
That should make sorting out the rest of the files fairly straightforward.
Oh, and get a lawyer.
The key thing isn't technology - yes, maybe we can create a robot that can do "human" tasks in 50 or so years. The issue is economics - why create a McRobot to serve fries at a significant capital investment when you can hire someone for minimum wage ? Why build a housework bot when people are still so cheap ?
My prediction
Personally, I hope (and believe) that small companies can beat the big mega-corps, both economically (GM makes only a couple of hundred dollars on the 20K car, whereas a decent software shop will make a couple hundred dollars on a USD500 software package), and as places to work. The political clout will remain with the mego-corps - you need deep pockets on Capitol Hill - but it looks like political clout is becoming increasingly meaningless in the US...
So, polarization is the name of the game. Good thing or bad thing ? I dunno, but I strongly believe it's going to be the way of the future....
for people who are passionate about it. For the "this looks like a good way to make a quick buck" brigade, I think the game is up...
Seriously, I've been through a couple of IT recessions, and it's never pretty. If you're good, care about your work and want to work hard, there are still plenty of opportunities. If you're into IT because it's well paid and involves no heavy lifting, you'll find it hard to get by untill the next boom (I've been through a couple of booms, as well). And in the confusion, lots of good people get laid off, and lots of clowns stay around - it's not fair, not clean and good people get screwed.
So, right now, IT is like most other jobs - if you're good, enjoy the work, and have people-skills, you'll probably be okay. If all you want is a fat paycheck in return for an MCSE, bad attitude and the ability to use TLAs without blushing, no, IT is pretty terrible right now...
RUP is a development process framework. It's sold as a bunch of documents/templates/intranet stuff, at a pretty eye-watering price. What's a development process framework ? It's a way of saying "when you start a software project, you usually need to go through a bunch of stages. For each of these stages, we have templates/guidelines/documents blah to help you build non-code artifacts (project plans, requirements documents, release notes, the whole kit & caboodle). Customize this to your organisation/project by choosing the stuff you need - out of the box, the process contains over 100 "artifacts", so you probably want to leave some out - and you will have all the tools you need other than an editor, compiler and caffeinated beverage vending machine to create world class software.
If I were running a major software team for a large, sophisticated organisation with a lot of cash to spend, I'd definitely look for something like the RUP. It requires a significant investment of time, effort and money, but just deciding how you're going to build software is a cathartic process, and it flushes out all the views people hold explicitly, rather than finding out halfway through that Fred doesn't believe in source code control, and Sue only works from CRC cards.
Check out "Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd Edition)" for a concrete example of how the RUP is applied - it's a lot more useful than the brochure-ware "books" I've seen.
If you are planning to create a new piece of software - hey, why not an operating system or something ? - and you don't expect to be in a position to actually sell anything for a few months, I'd stay away from the bureaucracy. Concentrate on the product, get it to a stage where you think you can sell it, and save your energy.
However, if you plan to run a consulting business, or plan to have people working alongside you, or plan to have frequent visitors - get an office. In the long run, if you can't afford to do the right thing now, you probably don't have the right backing to do this in the first place.
Risk category : eg. people risk (CTO gets hit by a bus), infrastructure risk (your server is destroyed by aliens), legal risk (you get sued by the RIAA for having an MP3 somewhere on your network), commercial risk (your biggest client goes bust), regulatory risk (the government licenses development shops) etc.
Risk impact
You then have to reach a business decision how much to spend on mitigating each risk. Clearly it's worth spending time on "high likelihood, disastrous impact" risks, but you may not care much about a transport strike stopping the cleaning staff from getting into work for a couple of days.
When you know which risks you care about, identify mitigation strategies. Typically, this starts with identifying an owner for the risk, who is in charge of the mitigation strategy. For instance, the development manager may have to find ways of mitigating the "top coder headhunted" risk by implementing code review processes, knowledge sharing systems, etc.
You should not let the business view risk management as a technology issue - it's a business issue. Risk mitigation has associated costs, either financial, time, or opportunity cost - the best way to avoid not getting paid for your work is to avoid working for unreliable bill payers. If you come up with a wonderful risk list and proposals for mitigation, your work will be wasted unless the business is willing to bear the cost of implementing your proposals.
IT management is made up of many disciplines - some technical, some financial, some project-based, and some people-based.
I'm a development manager, and there are a handful of books which I think stand out in those disciplines, but I know of only 2 which cover my role specifically : "Leading a Software Development Team" by Richard Whitehead (which I have not yet read), and "Herding Cats: A Primer for Programmers Who Lead Programmers" by by J. Hank Rainwater, which I've started and looks pretty good. You could also try "The Manager Pool" - again, mostly about development teams - or "Software for your head".
I agree that "Peopleware" is an absolute must - it's focussed on managing development teams rather than system administrators or helpdesk staff, but a lot of the principles apply to pretty much any kind of team.
On the whole, though, I'd suggest you look for books related to the specific disciplines you are interested in, and grab some stuff from the general business literature shelf - "Finance for non-financial managers", and "Influence" have both helped me enormously !
This book contains all you need to know about working on Win32, including a pretty comprehensive section on DLLs.
By all means, if you are proud of what you have done, blow that particular trumpet. But blow it in a key I can understand - "I was the application designer on a project which improved the performance of our webservers by doing xyz; we used the following technologies to achieve this".
The reason I get turned off by a big list of skills an individual claims to have is because I have found that - without context - they are almost impossible to evaluate. I have seen CVs which contain nothing but buzzword bingo entries, all rated at "Expert level" - I don't know anyone who is "Expert" at more than a handful of disciplines. I'd have to be desperate to even see someone who just tells me they can code in java but offers absolutely no idea how they used this in their career. Remember, my objective is to find the CVs which offer the best chance of actually getting a hire, not to evaluate every candidate as a person. It's great to see a summary - "I'm an expert at X, I've done a lot of Y and Z, and I have experience in the following environments".
When I say "I like to see something unusual" I mean people who show some spark of individuality in their CV - I've hired people who are passionate pianists, who have worked as bricklayers before turning to IT, people who have worked oversees as volunteers, and I have tried very hard to get a team with someone from every continent - do you know how hard it is to find an antarctican ? It's been my experience that people who have other interests outside IT tend to be easier to work with - this is not universally true, it's a pretty solid heuristic.
Don't get me wrong - technical abilities are very important to me. But I nearly always prefer potential over experience, and it's very rare for me to hire someone who is technically excellent but hard to get along with. And that is why I look for resumes which are well written, show some contact with the world outside of the candidate's job, and generally gives the impression that the candidate is professional and communicates well.
The whole selection process is all about filtering out as many people as you can, as early as possible.
I once had to hire around 20 developers in a 6 month period, while managing the team through a pretty hairy crisis situation. The only way I could do that is by increasing the likelihood of getting a hire for every interview I did. To do that, I developed some heuristics
This process basically gives you 3 piles : rejects, shortlist, and maybes. I'd see the shortlisted folk immediately, and put the maybes through some pre-screening exercise rather than see every single one of them.
I don't particularly believe in psychometric testing when recruiting for technical positions - in fact, I think having a diverse set of characteristics in the team helps - but I would definitely ask people to sit a technical test before getting to see a "real" interviewer. I wouldn't be surprised if many organisations use psychometric tests to thin out the interview list even though most psychometric experts point out that this is not a particularly sensible way to act.
I don't know what the job market is like where you are, but in the UK it's pretty tight. You may have been in someone's "maybe" pile, and they just wanted to slim it down - it's not a personal slight, the company may not even be clueless, and if I were you, I'd concentrate on improving my CV to hit the "definite" pile.
if you phrase the issue in technical terms, you let the business folk off the hook. I have some experience with Peoplesoft, and it's hoodoo-ware - it's expensive to buy, it's typically sold at a senior executive level ("all your problems will be solved by our magical software ! Sure, it's expensive, but think about the benefits ! Oh, and if it doesn't quite work for you, you should change your business processes so they fit our software"), and it can be a little temperamental, so people who have it running tend not to like to mess with it.
By saying "there are sound technical reasons why not using HTTPS is a risk", you leave the debate at the technical level; most business folk I've met tend to think that they should not interfere in technical matters (and this is typically a view we techies like to reinforce). So they will leave it to the technical management team. And the technical managers will realize very quickly that they will gain nothing politically by jumping on this - the best they can hope for is that they don't break the application which cost the organisation a lot of time, money and political heartache.
If you phrase it as a business issue - not a black and white binary choice, but as a risk and cost issue. For instance, I would send a brief note to the head of HR (or the head of finance if you're also using it for accounting etc.), copied your boss and the head of IT, and explain that there is a risk that information managed by Peoplesoft being intercepted; that the information being intercepted may include usernames and passwords which allow unauthorised access to the application.
Explain that the risk is not purely hypothetical, and offer to explain in more detail, but don't get into the specifics. You can then suggest which options are available; do nothing - the business may decide the risk is not worth the cost of the fix, implement HTTPS and deal with stability issues as they arise (explain that this may cause inconvenience to end users), or investigate further. You may even be able to get one of the Peoplesoft team to dig up documentation from the Peoplesoft extranet - it used to contain a lot of very specific implementation instructions, and the Professional Services team were not always up to speed with them.
Whether this is career-limiting is hard to tell; it depends on your organisation and specifically on your boss (and their boss). In my experience, Peoplesoft implementations are politically very sensitive because they nearly always coincide with business change, and that means there are going to be winners and losers. It's quite likely the IT management team don't want to hear the word Peoplesoft ever again. If you are worried about the politics, find someone you can talk to who is plugged into the politics - it may well be in your interest to keep quiet for a while, until the implementation settles down....
unlike eXtreme Programming, which is mainly about coding.
Scrum is all about managing the project, and in a way which matches the reality I perceive better than "traditional" models.
I've read the book in question, and I believe in Agile methods. One of the comments above says "methodologies are nowhere near as important as people" - check out the Agile Manifesto; line 1 says "we value individuals and interactions over processes and tools". Ken Schwaber (and Jeff Sutherland, who posted a reply here) are co-signatories.
The big problem I have found with Agile methods is that often the senior management team is unwilling to relinquish the impression of control over their projects. They insist on knowing everything up front - time, scope, budget - and even if they understand the empirical nature of software projects, that sense of control is very hard to give up.
I have found many of the "Top-down" implementations of Agile processes to be buzzword driven - the last thing you need to do Scrum is a new VP; the Scrum is intended to make the VP redundant ! I'm not surprised many people have had bad experiences with XP - the 12 practices are finely balanced, and distorting that balance (e.g. by over-emphasizing "the simplest thing that could possibly work") is a great way to ruin a project. Of course, I'm inclined to believe those organisations will struggle with any methodology; one thing Agile methodologies seem to do is draw out organisational weaknesses.
I'm working on a project right now where we have a very agressive schedule; we are pretty sure we can code the thing, but because our average corporate decision takes longer to reach than the project's timeline, we're hitting some rough spells. The cause is the decision making process; the effect is an unhappy project. In a "traditional" project, with analysts and project managers etc. and a sizeable up-front analysis phase, our corporate weakness would be less obvious; because we're saying "decide today, we'll have working code by the end of the week", our inability to decide is highlighted.
I'd recommend Ken's book; it's worth reading, and even if you don't agree with all he has to say, you might learn something.
The stuff which differentiates web projects - in my experience - is
they tend to have very compressed schedules
they are usually very visual - stakeholders can usually see both their own site and a bazillion other sites on the web; a lot of requirements discussions seem to to go something like "make it like amazon when you see the homepage, and like dell when you buy something, but make it nice and light like google and...". This is pretty hard to capture in a requirements document...the visual nature of web projects tends to lead people to assume the underlying stuff is easy to understand too ("I know we're selling books, but if you just make it do auctions like ebay we could earn an additional bazillion dollars")
many of the techniques that help you develop solid code are not easy to adapt to web development, e.g. unit testing, automated system & regression testing, there are comparitively few design patterns catalogued (the "Core J2EE patterns" book is about the bestI've seen thus far, and that is platform-specific), etc.
A lot of web projects are exploratory in nature - both for the business and in the technology used. It's hard to build a solid code base from a prototype.
The shared risk issue is not really specific to the web - it's a common issue with consulting style contracts.
That's not what I thought was annoying - it was the very condescending tone this book takes towards the business folk.
At best, this is consultant mumbo jumbo - "just you leave all the difficult stuff to me, I have a brain the size of a planet and will prove it by saying the word "synergistic" a lot".
At worst, it's precisely why we techies tend to get a bad reputation in many businesses. Many business people may find it hard to express their knowledge in the terms that we techies like; much of what they do may be hard to encode in nice UML diagrams, but they do not deserve to be treated like idiots. And that is the distinct impression I got from this book - the authors seem to imply their knowledge is infinitely superior to that of their customers, even when it concerns the customer's own business.
If you read the review again, you should find I do not claim SQL is never embedded within web pages; I simply object to the many unsubstantiated, sweeping statements that litter this book, often left dangling with very little context.
the point is the sweeping statements that litter this book, often implying that Web XP (which after reading this book was still a pretty hazy concept to me) is the only solution. The quote in question is from a section about the team roles in Web XP projects - it is almost left dangling on its own - there's no discussion about the problem, and none about possible solutions.
Have I seen a lot of embedded SQL in my time ? Sure - I've even written some. Is Web XP the only cure for this evil ? Uh...no. In fact, does any process shield you from poor design or poor implementation ? Well, no, probably not.
Another quote that annoyed me : while talking about the quality of web site code, "Few developers used an object oriented approach to development. Most used procedural languages, which made refactoring code or making changes to it much more difficult". Well, I'm a bit of an object bigot, but I would contend that the key tension here is not OO versus procedural, but rather time versus quality. I've worked on code in procedural languages that was very easy to work with, and OO systems which were an unholy mess. The reason many web sites are brittle is not that they don't use the right inheritance tree, but rather that they are put together in a very short space of time, and with ever-changing requirements.
I don't think OSS is making a big dent in MS revenues - it's still virtually impossible to buy a new PC without windows pre-installed (and pre-licensed).
Instead, I think MS is suffering from a lack of innovation. There is simply no compelling reason for corporates to upgrade their software anymore - Windows 2K is fine for business use, they don't get anything in XP other than support problems. You might upgrade Office to be able to read other people's files, but there are precious few "must-have" features to differentiate the current offering from Office 97.
The most significant reason for users to upgrade in the recent past has been MS's change in licensing policy - signing up before the deadline gives "free" access to upgrades for a limited period. I know that many corporates bitterly resented this pressure. However, the next version of "Windows for Servers" keeps getting pushed back, and many corporates are only now upgrading their servers from NT4 to W2K - not to take advantage of new features, but because support is being withdrawn.
So, while OSS is undoubtedly snapping at MS's heels, providing a much-needed alternative and nibbling away at the revenues, the bigger problem is that historically, Microsoft have taken ideas developed elsewhere and "embraced and extended" them. Right now, there are precious few radically new ideas to embrace, and the only way for MS to continue to grow their revenue is to find new must-have features. In short, they need to innovate under their own power.
Welcome to the real world, Bill....
Kent Beck - co-author of JUnit - recently published "Test-Driven Development", a book about how you can change your coding habits by creating the tests up front.
One of the most useful sections is a complete walk-through of the creation of unit-testing tool for Python - it's probably the best way of understanding the internals of the JUnit framework without trying to reconstruct every single line of code...
A previous poster has already mentioned XP - personally, I think the idea of gtetting your customer to do acceptance tests is pretty powerful in this case.
/.), suppliers usually end up not getting paid. You may not be able to afford to turn down the work, but can you afford to work without getting paid ?
If you have someone from your customer working alongside you, helping you make prioritisation decisions, seeing the progress you're making day after day, you stand a far better chance of having the schedule discussion in a fruitful way.
Most companies have been bitterly disappointed by development projects, and web projects seem to be particularly contentious. Most business folk aren't stupid - but they have been told so much bullsh*t by technical types that they are unlikely to believe you when you say "Trust me, I'm a professional, I alone have the magic mojo to know the future". They need to see first hand that you are someone who delivers (regular small deliveries are far better than a big release after months of frantic coding), who understands their business (user stories and the planning game establish your credibility) and who delivers quality solutions (unit testing and acceptance testing).
It sounds like your prospect has been burnt before - how did they end up with a front end but no back end ? - so the best thing you can do is establish credibility not through making statements about what is and is not possible, but by explaining your doubts and saying "I'm gonna take this job, on these conditions : 1. we look at the deal in a week, and both parties can walk away if we're not happy. 2, someone from your business comes to work with me as an acceptance tester and business guru. They tell me what is and is not important, and tell me when it's good enough". You should be able to make decent progress in a week (if your project allows, 2 weeks would be better...), and at the end your onsite customer will understand the realities of the situation. You can then look at the schedule again using "yesterday's weather" (the easiest way of estimating how quickly you're going to get through your work is to look at progress to date) as the measure of likely success. If you have worked hard, but completed too little of the project to be likely to finish on time, you have a leg to stand on.
The XP principle of building only what you need to get today's tasks done is esp. going to help you out - one problem of database design is that it's very easy to get tied up in beautifully elegant schema designs which almost, but not quite, work.
2 final points : invest in a bug tracker, even if it's a spreadsheet or card index. By using bugzilla or something similar, you can allow your customer to contribute bugs and see the bug list - and you won't forget to fix a little shortcut later.
You also want to make sure you're going to get paid ideally in advance. When development projects go wrong (and let's face it, this one doesn't look too promising regardless of the collected wisdom of
There's a bunch of stuff I do when trying to remain productive but without the immediate inspiration.
/., IRC, IM, dilbert, userfriendly etc. exist ?
- Refactor. Look at my work to date, and see if there are things I could improve without adding new features or changing the external behaviour. Refactoring steps should take a fairly short time - it usually takes me around 30 minutes to make a "normal" improvement. I often get a flash of inspiration during that time, so once I've finished the refactoring I have something new to move on to.
- I believe very strongly in using test driven design (there's a book by Kent Beck on the topic which I recommend). When I'm stuck, I like to create additional unit tests for functionality I know I'm going to be implementing in the next day or so. Doing so exposes new ideas and insights, usually enough to get me back to coding the business functionality. You could argue that test driven development is a very strong antidote for the malaise you describe because it forces you, the programmer, to create many micro-tasks (unit tests) and complete them several times every day.
- Browse the books that seem to inspire me to write better solutions : Design Patterns (Gamma, Helm, Vlissides, Johnson), Agile Software Development (Robert Martin). Usually I recognize something appropriate to my current project, and get inspired to improve it...
- Code reviews : get someone to review my code, review someone else's code. Fresh eyes, new ideas, the joy of communication....It's really easy to get bogged down in the detail of my current project. I like being able to look over the parapet and remind myself of the bigger picture, but in the most concrete way - by looking at the code.
- Hey, why else does
I am an infrequent Java programmer, but I found this book extremely useful when thinking about design in other languages. Much of the advice about how to fashion reusable libraries, how to think of the users of your class as potential wrong-doers is extremely useful.
While most of the other posts have concentrated on the security aspects, the project management side of developing e-commerce sites is also a nightmare. Most projects I've worked on have caused either the customer to be unhappy because their (vague, unstated) expectations weren't met, or the supplier to be unhappy because their (inarticulate, overpriced) staff was working 80 hour weeks and they didn't get paid enough.
Developing in-house capability is hard - you need to have a bunch of expensive techies running around, someone to manage them and the client, and you get stuck with maintenance and support issues ("we're such a good client, could you not just change it for free ?").
I would look around for a local software development shop - ideally around the same size as you - and form a (more or less formal) partnership. If you have customers who want e-commerce capability, you bring the customer relationship, branding capabilities are and account management. The technical partner brings project management, technical skills and maintenance/support capacity.
That way, you are less likely to end up with unhappy customers - at least if you choose a decent partner - and you don't have to invest a lot of time, effort and money in an area you're not equiped to exceed in.
Read "eXtreme programming for web projects" to see some of the joy that awaits you - even if you do look for a partnership...
is iterative design. Which is becoming fairly widely accepted in OO circles, and almost universally accepted in Agile circles.
Databases, however, are a lot harder to iterate - the cost of change is higher than with any other code. Martin Fowler is laying down an approach to manage (not reduce - manage) that cost, and it all comes down to a guess we have to make - do we think the overall cost/benefit tradeoff of an iterative process is better than a Big Design Up Front process ?
On the eXtreme Programming mailing list, there's been a lot of discussion about how to deal with databases - some deny the need for databases altogether, some advocate using Mock Objects for testing and even development etc. It all boils down to the cost of change - it's expensive to change a database design because it is very hard to identify the knock-on effects. Some changes are relatively easy to manage - adding a column is unlikely to actually break anything - but others can wreak havoc with existing applications - changing the type or size of a column for instance.
I'd love to think that the next big improvement in software development tools is not going to be yet another language but a sensible way of tying objects to their persisted data. All the solutions I've seen so far are bolted-on - they either force the database into unnatural positions, or make the objects fit into a model that's not quite what they'd be otherwise.
In the meantime, this article is well worth investigating - the idea of evolving the datamodel in tandem with the migration scripts is very powerful.
but I am.
Slashdot is not the place to ask this question. Even if you had given us enough information - which other posts have already told you is not the case - developers are notoriously bad at estimating the amount of time required to do anything. We tend to confuse "simple" with "quick". I can't count the number of times I've seen a task and thought "That looks easy - I already know how to do that - I'll give myself a bit of free time and say 2 days". Then I find myself a week later still hacking out "simple" code - there just turns out to be a lot of it.
The opposite is of course also true - I've frequently been asked to solve a problem and thought "wow - that's really hard to do in a clean way. I gotta take a couple of weeks just to figure out how to do it - better say a month" when there's a nasty hack that can be implemented in an afternoon.
So, what is the evil answer to your question ? Get some hapless consulting firms (3 should be enough) to quote for the work. They will force you to specify what it is you want in a lot more detail ( a useful exercise in its own right), and make up a number. Ask for their hourly rate and you should be able to come up with a decent idea.
You should also read Steve McConnel's "Rapid Development" - it is full of fairly scientific ways of estimating software projects (and it's pretty readable even for a non techy), and you could do should read Cockburn's "Agile Software Development" book for ideas about how to break out of the "but I have to know how much it's gonna cost before commiting" cycle.