The difference is not so much in how familiar we are with constructing bridges as in the fact that constructing a bridge is dealing largely with matter. While dealing with matter involves many challenges, far more of the parameters are relatively fixed - mass, tensile strength, density are all within well-understood boundaries.
Compare this with software. Often, the basics from which we construct software, as well is it's boundaries and requirements, are nowhere near as well understood. Often, they consist of other abstract constructs - business rules, corporate policies, usability guidelines. They might be instantiated in some way - test cases, software components, interfaces to other systems. In some cases - e.g. embedded software - the boundaries are with tangible objects.
One could thus suggest that the design of a bridge and the design of software share many attributes - they are both largely involved with abstract concepts. Bridge designers work with numbers and formulae representing the real world properties of their materials, requirements etc. Software designers deal with abstract representations of the real world for which their software is intended.
However, there are also many differences.
Bridge designers have usually got a larger body of previous work from which to re-use solutions. While the Patterns movement is making headway, and there is an increasing body of informal knowledge, we developers still have to re-invent a lot of wheels; for many domains, there's often simply no published information available.
Everybody knows what to expect from the bridge, and the outcome of building the bridge is usually pretty unambiguous. It's rare for the people paying for bridges to disagree about it's purpose, and I know of no occasions when the marketing director decides - halfway through construction - that the bridge needs to cater for trains as well as cars. The intangible nature of software means that it's hard to explain what the software "does" until it's finished. This in turn frequently leads to conflicts between stakeholders - "it's an order processing system !" - "no, it's a sales force automation tool" - "no, it's an interface to our accounting software". This is why most software methodologies contrate on either improving the quality of the specification and the way it is communicated (e.g. the Unified Rational Process), or on producing tangible results early in the process, and making it cheap to change (eXtreme Programming, for instance).
Once a bridge design is complete, the "construction" phase is typically conceptually straightforward - there are a lot of practical problems at a micro level, but the purpose of the design is to make sure that two teams starting at opposite sides of the river meet in an agreed place. With software development, I have found that conceptual problems extend all the way from the high-level design to the detailed implementation. No matter how well-thought out your object model, there are always details which are conceptually hard to solve. It's not unheard of for 2 software components which were designed to be compatible to fight like cat and dog when introduced to each other in the wild...
I believe that trying to compare software development with other disciplines is futile. Software development is a unique discipline, with many disparate specialisations and a short history. It combines craftmanship with engineering disciplines, math with instinct, and no two projects are ever identical. That's why it's exciting (to me, at least), but that is also why it is such a difficult thing to do well.
Most of the responses have concentrated on which of the servlet engines people have used.
I believe you need to focus more on the application - the performance of the best servlet engine can be crippled by a poorly designed application. Cocoon (and XML/XSLT in general) is not the fastest way to render a page.
I'm assuming you've invested enough time and effort into your cocoon development to be reluctant to throw it out. I would therefore suggest rigging your cocoon components to output performance logging information, put together a load testing infrastructure, and see what happens. Work out where your bottlenecks are (usually I find one or two bits of functionality which consume disproportionate amounts of time/resource), and see whether they can be optimised. Caching will yield significant benefits, esp. if you use relatively static information.
Only once you understand the performance characteristics of your application is it time to look at the infrastructure and see whether it addresses your application's requirements. For instance, improving the performance of your JVM is unlikely to yield any benefits if your application spends 80% of it's time doing XSL transformations.
FWIW, I think the Tomcat server is plenty fast enough for mainstream use; it's usually cheaper to add load-balanced hardware than pay for a commercial product.
Different people mean different things when they use the word "Portal", or "Content Management System". I have worked with one of the market leaders - Vignette - and their product is largely "framework" - you get very little out of the box, and have to do a lot of work to get something running that matches your particular requirements. Even though they sell themselves as a Content Management System, they don't support revisioning of documents. On the other hand, products like Zope or PHP-Nuke - which also fall under the broad category - are far more like "web-site in a box" applications for content-driven, community-based websites. On the whole, the big-ticket commercial systems tend to address a bunch of narrow concerns (e.g. documentum is very good at document management, Interwoven is very good at web-based workflow-driven content management), but often are weak in other areas (Vignette (certainly in the pre-version 6 days) is very poor at dynamic functionality so forums etc. are difficult to implement. I would suggest that you make sure any evaluation adequately addresses all the features you require, and ask for reference sites. We didn't and got burnt very badly as a result.
As far as open software goes, I like Cocoon. It requires you to do a lot of work, but should be very easy to work with once you've got it up and running. On the other hand, if you don't want to spend your life working on the portal, get Zope or PHP-Nuke, install it and walk away. They'll prob. do 90% of what you want, and are pretty easy to support.
The fundamental question seems to be : Do processes make better software I've been involved with a lot of software projects (though never contributed much to Open Source...), and I have never seen a single project that was succesful because it followed a process. Nevertheless, whenever a project runs into trouble, the first call is usually for "more/better process !!". So let's look at this in more detail.
Succesful projects seem to grow their own process. The process seems to be simple, and often appears to be way less than you would expect, and rely heavily on interpersonal communication rather than documents and frameworks. There's usual a small core of "gatekeepers" who set the technical and philosophical tone for the project. The Linux kernel is a good example.
I am very worried about people using phrases like "mature process", "industry standard" etc. - in my experience, this often refers to the Rational Unified Process or the Software Engineering Institute's Capability Maturity Model. Both are laudable and when I go on holiday, I really want the airplane's control systems to be written using such processes. However, for many projects, the burden of bureaucracy is inappropriate (yes, I know you can tailor the RUP to suit your needs, but it contains over 140 different deliverables, none of which appears to be code). The training required to bring developers up to speed with these processes is significant, and usually expensive.
Instead, I'd look at the Agile methodologies at Agile Alliance website. The "Crystal" methodologies are especially interesting because they encourage you to actively choose the processes your project needs based on a variety of parameters - size, risk etc.
Having said that, I think a lot of the problems addressed are real - I think they get solved by people, not processes though.
I've never worked in a NOC, but I've been a customer with a couple of big names, and the most important thing to a customer is not the SLA - if we have to even read it, things have gone seriously wrong, and rather than litigate, we'll just leave.
The blinkenlights, CRM processes, trouble ticketing systems etc are all lovely, but the thing that makes a difference is the people. In one case, there were 2 network guys we spoke to - one was great, used his initiative to sort stuff out, never lied to us or tried to fob us off, and kept us in the loop with what was going on. The other guy was technically prob. better, but used all the company's processes to hide from us. He was reluctant to acknowledge problems, rarely responded to voice or email, and gave the impression we were not really important to him. They both worked to the same SLA, processes, standards, etc. One was good at his job, the other merely good at technology.
So, I would suggest that instead of spending a lot of time on SLAs, you spend time finding good people. Monitor your performance not by "uptime" (one of our suppliers was monitoring our site using the internal network. They got 99.999% uptime, while anyone outside the NOC got "server not found"), but by customer satisfaction - contact your customers once every 3-6 months and ask them to fill out a satisfaction survey. Deal with issues they raise. Treat a customer who leaves you like a company crisis. Encourage your people to think about outcomes, not processes.
Sure, you need to know how your network is performing, what your customer's uptime statistics are, and have the facilities we have come to expect (including blinkenlights). Just make sure you've also got some cat5, screwdrivers, and free drinks for your customers, and that you don't get carried away with all the fancy stuff.
When you can imagine querying the data you are entering - you can't easily query images, or other binary data (although I guess there must be someone working on this problem somewhere...). If you can't query it, you should usually find a better place to store it - NAS is usually fine - and maintain a pointer to it (e.g. a filename). Yes, it's something that can get un-synced, but most databases suck when it comes to actually dealing with binary data, and you can use that capacity a lot more effectively elsewhere.
When the structure of the data is likely to remain stable. If your application deals with well-understood entities, whose properties are unlikely to change over time, a database is a great solution. Databases are, however, relatively change-resistant - it's typically a pain in the backside to change the datatype of a column, remove columns etc. So, if you're working in a domain where you continuously learn new things about your core entities, or if your development processes are highly iterative, you might be better off using an alternative data storage mechanism.
When more than a single user is likely to access the data - yes, you can create locking mechanisms yourself. You can also take your own garbage to the local dump. It's usually not a good use of your time, and the cost of not dealing with the issues involved are expensive, both for garbage and concurrent access to shared data.
When you require consistency accross transactions - the good old ACID (atomicity, consistency, isolation, durability) principles which become important for many non-trivial applications.
If you care about enforcing rules of referential integrity - do you want to ensure that all the tracks in your record collection can be tied back to a recording ? Do all orders have to have a customer ? Those things are far simpler to implement with an RDBMS than in code.
There are instances where using an RDBMS is not appropriate. Ones that spring to mind are : - your business domain is not well understood or liable to rapid change. In this case, the cost of change for database objects is likely to be a problem - consider storing data in a self-describing format like XML. - the application domain doesn't lend itself to being described in relational terms - image manipulation tools, word processors etc. which deal with mainly binary information probably should not use a relational model for their core data structures.
Alternatives exist - Object Oriented databases are becoming more and more popular. I have way too little experience with these to comment on their use.
you should definitely read up on this (though I am not aware of any first-rate books on managing customer support), and get a decent theoretical grounding in the subject.
However, I think most vendors emphasize the tools over the people using them. I'd suggest working on allowing the people working in your team to do the best work they possibly can do - protect them from corporate politics, establish a good relationship with whoever can fix actual problems you have to escalate, get them whatever tools they ask for, and make sure you have a decent working environment.
If you have to grow the team, make sure you hire the very best - ideally give the existing team a say in the process.
At the end of the day, the attitude of the person answering the phone is a lot more important to the customer than which trouble ticket system you use...
I have worked for a large, multi-national consulting firm (business as well as IT), and the key factor that made us succesful was that we established very clear measures to manage the sales and delivery processes.
Specifically, we changed the reward system for sales people so they were rewarded for the profit of the job, rather than the revenue. This meant that it was in their interest to avoid under-estimating the project, and ensured the sales team remained involved after the initial sale was completed. As they are usually the people with the relationship with the customer and the insight into their requirements; often, they're also better at negotiating the inevitable changes to the project as delivery progresses.
We also established a system for measuring profitability of assignments, and individual's constributions towards that profit (based on somewhat arbitrary but totally transparent rules); again, individuals (the entire assignment team, not just the sales team) were rewarded for their contribution to that profit.
The outcome was that we ended up with less failed assignments caused by under-bidding, and a happier relationship between the sales team and the delivery teams - the sales guys worked with the delivery team to protect their slice of the profit pie, and didn't disappear the minute the contract was signed. The sales guys concentrated on opportunities that offered significant opportunity for profit, and typically looked for longer assignments rather than placing a couple of people here and there just to get the revenue figures up.
You might want to read David Maister's "managing the professional service firm" - most of these ideas are documented in that book.
Once you have worked those issues out, look at development methodologies. I'd recommend Alastair Cockburn's Crystal methodologies which may be easier to sell than some of the more radical Agile methods. To do business with major clients, you will almost certainly want to look at the Rational Unified Process (RUP, www.rational.com), which is almost a "meta-process" - you choose the elements you choose from a range of processes, practices and deliverables.
The reason latin helps me in my career - I took 6 years of Latin at a Dutch secondary school - is because it forces you to be extremely precise in the way you think. Modern languages allow a certain amount of ambiguity - English notoriously so - in the way you express yourself. Latin - like code - requires you to specify exactly what you mean.
The cool thing was that - after a few years - latin became second nature. It was no longer necessary to laboriously parse each word to make sense of the sentence, instead, the meaning started to become clear from the whole construct. I have found this to be the case with code as well - after a while, you no longer worry about the syntax of a given language, but rather move up a level to looking at the architecture as a whole.
Would I recommend Latin to anyone who has the option ? Only if you persevere. The first couple of years were tedious and frustrating; there's a lot of memorizing of stuff that appears to be complex for its own sake, and you have to work very hard to get even small results.
After you have the basics though, it becomes very rewarding - all western european languages become easier, the clarity of thought Latin brings with it pays handsome dividends, and we got to translate texts that were basically pornographic. There's nothing better than being 16 years old and having to translate porn for your homework. Oh, well, maybe there is....
The link with science and law is more about the absolute clarity of thought required than about the fact there's a bunch of words those disciplines borrowed or inherited from a dead language...
DeMarco is a pretty cool guy...
on
Slack
·
· Score: 2
I went to a workshop he ran with Tim Lister and the Atlantic Systems Guild. Well worth the time and money.
Also check out "The Deadline" - a novel about project management. Really.
Yeah, my parents only had a world war to deal with
on
Generation Wrecked
·
· Score: 2
they had it easy. They never knew the pain of dealing with the falling value of stock options, not having the smartest car on the block, or falling behind in the gadget race. Maybe we should get a medal or sumthin
If you did - or bought something from an online retailer, or stored sensitive or valuable information stored on a computer that is connected to the internet....
There's definitely a lot of FUD sown by the "security" industry. I also agree that the media don't always treat the subject responsibly - events involving any kind of computer usually get cloaked in semi-accurate buzzwords implying the use of magical incantations and mysterious underground organisations, when usually it's a bored teenager trying to hack into a porn site.
On the other hand, there are serious security breaches every day - and script kiddies can do as much damage as a responsible hacker - more, because they often don't understand their tools very well. If nothing else, you need to protect your system against them.
If you write software that can be used by total strangers across the internet, you need to assume that some of them will have unpleasant motives and will attempt to cause your software harm. It doesn't matter if this applies to 0.001% - if you are dealing with sensitive data, providing a public service or rely on your income from your online application, if just one script kiddy brings your site down, you've lost the ball game.
I think anyone who is involved with online application development should at least look at books like this, and if you're the technical lead you should make sure you understand exactly what your application is going to be up against. The numbers don't matter - just one visitor is enough to do irreparable harm to your site.
as a techy, you have to consider what the real nature of your job is. Do you get paid for cranking out code/building servers/tuning networks/administering boxen/installing cool stuff ? Uh...no. You get paid to make things better in the company than they would otherwise be. I hate using the expression "adding value", but that's what it boils down to.
So, how do you make things better than they might otherwise be ? Being uber-competent at your specialisation is a good start, but being able to communicate and work as part of a team is usually even more important. So, when someone asks you something, just about the worst approach is "the moment their lips started to flap I could see they were monumentally stupid and deserved to be mocked behind their backs on some geeky web site". It's your job to make things better - that means listening to ideas from sources you wouldn't normally consider (your boss' boss), and treating their input with some respect. And guess what ? If you take a little time to explore the idea with people, they can usually work out it isn't going to work. If you handle the conversation in a professional way, and show you're being thoughtful and thorough, after a few times you won't get the "I have to say something to justify my presence at this meeting" kind of input - people will start to trust your recommendations and plans. Of course, you could just do the pained "that idea is so stupid I can't believe you tie your own shoe-laces" attitude thing, and you'll find the non-techies will fear and loathe you, and secretly delight in sending you on GFAR exercises.
You could not implement most of the GoF patterns in a language that doesn't support the core OO concepts ("Design Patterns for assembler" anyone ?).
Or rather, I would suggest that most if not all languages have un-documented patterns waiting to be published - but what works well in a java environment doesn't work in assembler and vice versa.
"A pattern is an idea that has been useful in one practical context and will probably be useful in others". (martin fowler).
Of course there are other definitions, but most include the word "context". The language in which you are approaching the problem is definintely part of that "context" - so I think there is definitely a place for an explanation of how to implement well-known patterns in a specific language.
Having said that, I think there's a trend towards "rip-off" pattern books which add too little value - I recently read "J2EE design patterns applied", which allegedly expands on the Core j2ee patterns book. It's not very good...
After a project has gone "live", we maintain a bug-fix team for a short while to do the hand-holding. Once this team starts to look bored, the people get assigned to new projects.
Any new work is carefully analyzed - only critical bugs are fixed without delay. All non-critical bugs, feature requests, and other bits'n'pieces (documentation, testing for new platforms, end-user support etc.) is put into the great big "new work" pot. It's then prioritized alongside all the other stuff.
This forces the business guys to consciously trade work on existing software against new projects, and it avoids the situation where a developer is inundated with trivial bugs and/or feature requests - we found that many "bugs" were actually new features that nobody had thought about during the main development cycle. This is not necessarily a bad thing - many of the features were terrific ideas which added a lot of value. However, by forcing the business to trade off between those features and all the other stuff they wanted, developers can concentrate on the areas business had explicitly stated were the most important.
We also introduced the concept of "ideal days" in our project planning. This comes from eXtreme Programming and basically requires you to measure roughly what proportion of your time you spend on your "main" project; projects are planned using this ratio, so if we know that Joe can only contribute 30% "ideal" time to the project, we can plan accordingly. It's not a reflection on Joe - it might mean he's stuck maintaining someone else's sucky code - but it avoids squeezing Joe like a lemon.
The book "Planning eXtreme Programming" is very useful in this respect - you may want to get your boss to read it.
and I've rarely chosen the lowest price bid; money is never the sole criterion for awarding a project.
Here's an example : we were evaluating an e-commerce solution. I worked with the internal developers to get a feel for what the technical impact of the solution would be, what the interfaces back to the main system would involve, the sort of performance and scaling issues we would expect etc. All these issues were made clear to the companies bidding for the work.
I asked the vendors to address these issues in their proposals, and outline their ideas for how to deal with them, together with rough time estimates.
Anyone who came back with nothing more than a price (and yes, that happened with a couple of vendors) got put aside : if you're bidding for a job without understanding it, we're both going to end up in trouble. Any vendor who didn't demonstrate at least a basic understanding of the requirements in their proposal and did not submit meaningful estimates was asked to go back and think about it again.
In the end, we chose a solution that fell in the upper quartile of the price range; we spent a lot of time talking to the vendor, and everyone knew what the other was expecting.
What does this boil down to ? Yes, there are some PHB types who behave irrationally in the vendor selection process. There are also those who know from experience that a partnership has to be win-win. You have to make enough money on the job to be able to do it well, and help us out when the unexpected happens without having to renegotiate. We need to get a quality deliverable from you, and give you enough information up front to make a reasonable guess at how much time it's gonna take you. If you don't demonstrate you fully understand the requirement, and show how come you can do it for the price you quote, I'm going to assume you haven't thought it through, and are going to run into trouble delivering the job.
The product should be available to try out with the least hassle possible - ideally as a free unlimited use download.
The product should come with excellent "read-me" instructions for installation and/or administration, and a really good "getting started" guide. I've downloaded a bazillion nifty looking tools which had no obvious "getting started" guide or "try this" intro.
The installer must be the best piece of software your organisation has ever crafted. It must be totally transparent what you're putting on my system, it must come with a working "uninstall" option, and it should take the effort to use words I already know when asking me questions - "should I fnurgle the foo, or sklarf the bar" is not helpful when confronted with a new piece of software. If your installer is professional, I am a lot more likely to believe the rest of the software is first-rate too.
Once the software is installed, give me lots of first-class examples to play with. I only read documentation when it hurts - I prefer working code.
Provide an interactive forum with knowledgeable people to help me when I run into trouble - usenet, mailing list or a messageboard are all great.
Provide great migration and/or integration tools for commonly used tools. For instance, if your product manages source code or something, help us out with sample "ant" build scripts, and integration options for the leading editors/ides.
Get a bunch of "boss-friendly" blurb ready so I can say to my boss I found a really cool pieve of software, and if you read this thing here you can see it's buzzword-compliant !
I don't mind the lock-in much - it's kinda inescapable for many serious products - but at least be honest and upfront. Provide a place where I can find out about your proprietary addtions and what to do to avoid them if I so choose.
Be upfront about the commercial impact of your products. Don't make me worry that I will end up having to pay through the nose to get your software working on an industrial scale - tell me upfront what the costs are.
People who do this well (outside the big names) are perforce - they make it really easy to find out about their software, try it, and get comfortable with it. jcorporate.com (home of the expresso framework for java development) are also pretty good - they have a decent mailing list and provide as much documentation as they can (though it appears they need some help there...). Good luck
Personally, I have found the traditional "skill-based" training to be largely a waste of time - I just don't enjoy working through a bunch of exercises with canned explanations, esp. if the trainer is a professional trainer as opposed to a professional developer/manager/architect or whatever. The IT training business (certainly in the United Kingdom) is pretty much industrialized, and geared towards turning out as many Microsoft-certified whassnames as possible. Attending a course with one of the big training shops is in my experience a case of working through a bunch of thick books with more-or-less real world examples with doctrinaire solutions. There is rarely an opportunity to explore alternative solutions, and the goal seems to be acquiring a bit of paper saying "MS certified whassname" rather than learning anything new.
On the other hand, I have attended a bunch of excellent "training" events such as those run by the Atlantic Systems Guild which includes Tom DeMarco and Tim Lister, where there was an agenda of topics to discuss, but little or no "here's a book, read it, and we'll do a bunch of exercises" nonsense. The format was "here's an idea, or a story that happened to us once - let's consider what it means for you", along with a bunch of hands-on sessions exploring some of the topics.
So, all this comes down to - work out what your learning preferences are (there's a questionaire here, and make sure you tailor your training to it if at all possible.
though it seems to run out of resources at a few hundred concurrent users. You can find it at jakarta.apache.org. It's not very sophisticated, but it can certainly perform basic load testing.
I've also used (Mercury's) LoadRunner, a fairly expensive and complex beast; it comes with a built in proxy which allows you to capture a browsing session as the basis for a test scenario - this is a particularly useful feature. The scenarios can be scripted, and there's a bunch of random timers you can use to represent "real-world" behaviour.
I'd suggest creating 2 types of test scenarios : 1 type to represent your best guess at "real world" usage, i.e. representing users browsing, spending time reading a page, clicking all over the shop etc. - this should give you a good idea of how your application is going to perform. The second type of test should provide you with metrics you can use when making improvements once you spot bottlenecks. They don't necessarily represent "real-world" activity, but allow you to measure whether code changes have made a difference. For example, you might have a test where all users log into the application simultaneously. In version 0.1 you can support 10 concurrent users; in version 0.5 100 concurrent users, and in version 1.0 250 users. These numbers don't represent "real" users - how likely are they to log in all at the same time ? It's a lot easier to manage your performance improvement work using these metrics.
than just a bunch of programming languages. Do you have experience of some particular kind of industry or an insight into how common business processes could be improved ? Do you have an idea for an application that you would use ? Are you a member of some as-yet under-marketed-to community with disposable income ? Have you been caught in some piece of customer service hell and thought "I know just how to improve this !" ? Alternatively, are you masters of some arcane piece of technical knowledge ? Do you communicate well with other techies ? Have you read every single book and article on a particular topic ?
Basically, you need to find a niche. No company of any size is going to hire a 2-person shop - the risks are too high. What happens if one of you gets sick ? What happens if the project requires more resources than you can throw at it ? As a development manager who has frequently bought in help from outside, I would not want to have to hire "two guys who know C++" and then go to "mega-shop.inc" for all the other staff - one project, one supplier. Of course, there are always the smaller companies you can work for, but they often only have small jobs; you basically end up working a few weeks, spending 2 weeks looking for new work - the ratio of paid-for work to "marketing time" works against you. Small business are also often late with paying you for your work - not always consciously, but it's a major hassle you just don't need.
So, if you want to go into the professional services business, find something you can do which nobody else can do. Sell your ability to improve your customer's business for them, rather than your ability to crank out code. Pick a sector - "vertical market" as a previous post has mentioned, or technology (I know a couple of guys who have formed a "database designers guild"; they are well known as the go-to guys for complex database issues. They don't work all that much, but they charge very high rates when they do work).
Establish a reputation in that area - if you have to, offer your services "on approval", i.e. a trial period or something during which the customer can back out without paying you for any of your time. I'd suggest not working for free though - it's bad for your bottom line, but more importantly, most business buyers just don't respect or trust the "free offer" sales pitch, they fear getting tied into a vendor with very high costs later. You almost certainly need to get a sales/marketing/business guy on board once you think you have a start. Techies don't make good sales people. You want to concentrate on delivering excellent work to your customers, not on sending out bills, making 20 or 30 sales calls a day, dealing with creditors and banks - it's not fun. Trust me on this.
Of course, if you look at yourselves honestly and say "we're just two guys who can code", you could still go for it and make all of us eat our words - Bill Gates and Paul Allen did it, so maybe you guys can too. I'd say the odds are against you - but it's your life. I'd suggest setting a bunch of targets and check points - something like "if we don't have our first client in 3 months, we'll quit. If we haven't been paid for our time in 5 months, we'll quit. If we haven't made enough to pay our bills in 9 months, we'll quit." etc.
check out ant at the apache project (www.apache.org). It's a tool for automatically building a java project - it uses an XML-based build file to specify the actions it should take.
We used it to:
check out all the code for a given project and/or branch from the source code control system
check out all the relevant config files and putting them in the appropriate place
compile everything that needs to get compiled
restart any services that need to be restarted
Of course, by creating different build targets, we could make a bunch of decisions in the build process, e.g precisely which files to check out (live didn't get some of the debug stuff compiled in, so didn't need a bunch of support code), which config elements to check out, whether to enable debug features etc.
You still end up with multiple config files and all the mess that goes with it, but because the build process is totally automated, it is a lot less error prone. You can think of the ant build file as a meta-config file, identifying your environments and their specific requirements etc.
I believe there are similar tools available for other programming environments - you could do something similar with "make" if you really wanted to - and you could use ant for non-java projects if you want to invest a bit of time.
As a general principle, I always like to see build processes automated - it allows you to create environments without needing the skills of your company sociopath, it enables developers to find bugs in the finished product by re-creating it quickly, and when bad stuff happens, you can recover without too much panic - you know that your automated build scripts work reliably, and you don't have to remember that the database connection relies on some obscure library that you have to download from an extinct website somewhere.
Check out www.xprogramming.com for more on the importance of regular builds.
Or even mediocre managers ? The "team lead" role is the worst position to be in - you have a whole load of resposibility, and almost no authority.
I'm guessing you haven't got the authority to fire your team (and I don't think it's the right solution anyway), hire more team members (ditto), change the scope of the project (this is more likely to yield results), or change the way you're working (bingo ! give the man a cigar !). You can't exert much formal control over the team, and you have to be careful with running to the senior management team, because they usually don't like to hear bad news.
So, I would suggest that you get the team together to do a semi-formal project assessment, compare actual to plan, that sort of thing. If things are as bad as you say they are, the team will likely recognize this; you can then declare an official "state of emergency" - note that you should do this without involving the managers at this stage. Suggest that you all spend a couple of hours brainstorming ways to get the project back on track. Sneakily, look into eXtreme Programming and / or Scrum - there are a couple of easily digest books available on both methodologies from your favourite patent owner.
I would suggest that in the brainstorm meeting, you steer the discussion towards ensuring progress visibility is the key priority. If the project is in trouble, you need to know how badly, what the backlog is, and what your current estimated delivery date is - it's the only way to measure your progress. This can be as simple as a spreadsheet on a file server with tasks and status (hint : accept only binary completeness indicators - otherwise you end up with lots of projects at "90% complete" status which turns out to be 30%. A task is complete or incomplete - final).
I would also suggest revisiting the original plan. I have found that it is usually better to allow people to make their own estimates and prioritisations, so ask everyone to adjust the estimates and dependencies, see where you're at - if you're gonna slip, find out today, rather than 2 days before shipping.
Next, you might want to discuss introducing iterations, ie complete, running, shippable software implementing one or more new features into the product. I've never worked on embedded products, so this may not work in your environment, but it really helps to improve the visibility of your progress when you know that you'll be delivering a complete application every 4 weeks or so. If you promise management/the customer/your mom to do a demo, it helps even more. It also ensures you don't have any last minute bugs to deal with on shipping day.
Work out - with the team - what you're going to do, and then do it. Don't tell anyone until you know it's gonna work. Make sure you stick with the changes, and enforce them. Review the situation after a week or 2; tune, repeat. If you find you're in such deep trouble you can't see a way to fix it, tell your boss the moment you know for certain you can't recover.
There are no magic bullets; stuff I can pretty much guarantee won't work are adding more people to the project (except if you have an exceptionally well-defined design and a lot of repetitive drudge-work to do). Bullying people and threatening to fire them is a surefire way to get them to spend their time honeing their curriculum vitae and surfing the job sites. Stuff that usually helps but may not be enough is improving visibility of project status, increasing the level of detail in the plan to binary 1-3 day tasks, and increasing the team's level of ownership of the plan.
Seriously, I doubt that cross-platform capabilities will be a huge issue (a previous post claimed that most serious contenders are cross-platform or at least web based - I reckon it's true...).
In my experience, these beasts come in 2 rough flavours : the "database with a front end" flavour at around the 500 USD mark, and the "help desk, ticketing, workflow, knowledgemanagement, coffee preparation and universe rescuing" flavour, at a price you only find out from the leather-bound ring binder of a fragrant sales representative.
If your company is going for the cheap flavour - pick one, learn to live with it. It will almost certainly not be quite right for you, but you should be able to make it do what you want.
If your company is going for the all-singing, all-dancing flavour, seriously consider whether you need it, and whether it would not be cheaper, easier and less painful to take that wad of currency and insert it into various bodily orifices.
Here's what I have found to be the case : regardless of the promises of the venduh, it will be expensive and difficult to customize the product to meet your needs; you are likely to end up with a kludge. The "value-added" components will cause more trouble than they solve - I have especially fond memories of an automated inventory application which didn't recognize my ergonomic keyboard and automatically raised helpdesk tickets for the support team to bring me a new keyboard; they religiously turned up every day for about 2 weeks with a newly ordered keyboard...doh.
The more politically active managers will use the data produced by the system to "prove" that one department or another is more expensive/productive/careless/likely to break company policy/set fire to the building than another. The better the reports from the helpdesk system, the more bitter the political battles.
The automatic email reminders will be forwarded to everybody's trash folder because of the false positives; of course, the vital real business-critical problem will not be spotted until the hard drive of the chief exec has been filled with pictures of britney spears, a chicken, and 3 gallons of maple syrup.
In short - with these things, I tend to feel that just a little less than enough is usually more than sufficient. It's a great way to waste enormous amounts of time, money, and credibility when you could be doing stuff for your customers.
As someone else has already mentioned, the process you describe is not strictly speaking regression testing.
I have worked on quite a large number of software projects, and every single one included "testing". The level to which software is tested, however, varies widely. One project I worked on was a billing application which collected the entire company's annual revenue. Yep, we tested that one pretty rigorously....But I've also worked on web site projects where the downside of getting it wrong was not so severe; we tested almost as an afterthought.
There are a lot of test "gurus", and a bunch of different methodologies to provide a testing framework. Checkout testing.com to get a feel for this...
It all boils down to the decision how much time do you spend on testing versus other quality assurance methods. Testing is the most expensive and least effective way of finding bugs except for releasing the code to your customers. Practices such as specification, design and code reviews, design-by-contract, aspect-based programming give you far more bang for your buck.
FWIW, on the billing project, we had a formal specification review to make sure that the product we built did what the business needed, a business representative to help fill in the blanks in the specification, a design review to make sure that the software we intended to build was indeed what the spefication asked for, and made sense in its own right. We produced numerous prototypes and mock-ups to get our customers to tell us we were on the right or wrong track without having to learn to read software design documents. During the code phase, we created unit and integration tests which measured the kinds of thing you mention (e.g. order total must equal sum of order lines), and had a dedicated test resource. We ran code reviews. We also made sure we showed the work in progress to our business sponsors as often as we could. When we thought we were done, we had a formal show-n-tell to present our work to the business; this lead to a bunch of rework, which again was tested, reviewed etc.
The software was succesful from the business point of view; with hindsight, I'd say that the code was truely awful, and I wish we'd spent more time on code reviews. How important was testing in the QA process ? It provided a useful yardstick to tell us how close we were to meeting our objectives. Would I have relied on testing without all the other stuff - reviews, prototypes, great access to the business folk ? Hell no - if you don't know that what you're testing is what the customer wants, your tests are pretty much valueless.
So, I guess I distrust any organisation that over-emphasizes testing as a QA process - there are better ways of avoiding bugs. On the other hand, you have to provide the appropriate level of testing - if you're writing nuclear missile guidance systems, you need to allocate a lot more resources to testing than if you're building a website to hail your cats' achievements as politicians.
Slashdot Mirror
The difference is not so much in how familiar we are with constructing bridges as in the fact that constructing a bridge is dealing largely with matter. While dealing with matter involves many challenges, far more of the parameters are relatively fixed - mass, tensile strength, density are all within well-understood boundaries.
Compare this with software. Often, the basics from which we construct software, as well is it's boundaries and requirements, are nowhere near as well understood. Often, they consist of other abstract constructs - business rules, corporate policies, usability guidelines. They might be instantiated in some way - test cases, software components, interfaces to other systems. In some cases - e.g. embedded software - the boundaries are with tangible objects.
One could thus suggest that the design of a bridge and the design of software share many attributes - they are both largely involved with abstract concepts. Bridge designers work with numbers and formulae representing the real world properties of their materials, requirements etc. Software designers deal with abstract representations of the real world for which their software is intended.
However, there are also many differences.
Bridge designers have usually got a larger body of previous work from which to re-use solutions. While the Patterns movement is making headway, and there is an increasing body of informal knowledge, we developers still have to re-invent a lot of wheels; for many domains, there's often simply no published information available.
Everybody knows what to expect from the bridge, and the outcome of building the bridge is usually pretty unambiguous. It's rare for the people paying for bridges to disagree about it's purpose, and I know of no occasions when the marketing director decides - halfway through construction - that the bridge needs to cater for trains as well as cars.
The intangible nature of software means that it's hard to explain what the software "does" until it's finished. This in turn frequently leads to conflicts between stakeholders - "it's an order processing system !" - "no, it's a sales force automation tool" - "no, it's an interface to our accounting software". This is why most software methodologies contrate on either improving the quality of the specification and the way it is communicated (e.g. the Unified Rational Process), or on producing tangible results early in the process, and making it cheap to change (eXtreme Programming, for instance).
Once a bridge design is complete, the "construction" phase is typically conceptually straightforward - there are a lot of practical problems at a micro level, but the purpose of the design is to make sure that two teams starting at opposite sides of the river meet in an agreed place.
With software development, I have found that conceptual problems extend all the way from the high-level design to the detailed implementation. No matter how well-thought out your object model, there are always details which are conceptually hard to solve. It's not unheard of for 2 software components which were designed to be compatible to fight like cat and dog when introduced to each other in the wild...
I believe that trying to compare software development with other disciplines is futile. Software development is a unique discipline, with many disparate specialisations and a short history. It combines craftmanship with engineering disciplines, math with instinct, and no two projects are ever identical. That's why it's exciting (to me, at least), but that is also why it is such a difficult thing to do well.
Most of the responses have concentrated on which of the servlet engines people have used.
I believe you need to focus more on the application - the performance of the best servlet engine can be crippled by a poorly designed application. Cocoon (and XML/XSLT in general) is not the fastest way to render a page.
I'm assuming you've invested enough time and effort into your cocoon development to be reluctant to throw it out. I would therefore suggest rigging your cocoon components to output performance logging information, put together a load testing infrastructure, and see what happens. Work out where your bottlenecks are (usually I find one or two bits of functionality which consume disproportionate amounts of time/resource), and see whether they can be optimised. Caching will yield significant benefits, esp. if you use relatively static information.
Only once you understand the performance characteristics of your application is it time to look at the infrastructure and see whether it addresses your application's requirements. For instance, improving the performance of your JVM is unlikely to yield any benefits if your application spends 80% of it's time doing XSL transformations.
FWIW, I think the Tomcat server is plenty fast enough for mainstream use; it's usually cheaper to add load-balanced hardware than pay for a commercial product.
Different people mean different things when they use the word "Portal", or "Content Management System".
I have worked with one of the market leaders - Vignette - and their product is largely "framework" - you get very little out of the box, and have to do a lot of work to get something running that matches your particular requirements. Even though they sell themselves as a Content Management System, they don't support revisioning of documents.
On the other hand, products like Zope or PHP-Nuke - which also fall under the broad category - are far more like "web-site in a box" applications for content-driven, community-based websites.
On the whole, the big-ticket commercial systems tend to address a bunch of narrow concerns (e.g. documentum is very good at document management, Interwoven is very good at web-based workflow-driven content management), but often are weak in other areas (Vignette (certainly in the pre-version 6 days) is very poor at dynamic functionality so forums etc. are difficult to implement. I would suggest that you make sure any evaluation adequately addresses all the features you require, and ask for reference sites. We didn't and got burnt very badly as a result.
As far as open software goes, I like Cocoon. It requires you to do a lot of work, but should be very easy to work with once you've got it up and running. On the other hand, if you don't want to spend your life working on the portal, get Zope or PHP-Nuke, install it and walk away. They'll prob. do 90% of what you want, and are pretty easy to support.
The fundamental question seems to be :
Do processes make better software
I've been involved with a lot of software projects (though never contributed much to Open Source...), and I have never seen a single project that was succesful because it followed a process. Nevertheless, whenever a project runs into trouble, the first call is usually for "more/better process !!". So let's look at this in more detail.
Succesful projects seem to grow their own process. The process seems to be simple, and often appears to be way less than you would expect, and rely heavily on interpersonal communication rather than documents and frameworks. There's usual a small core of "gatekeepers" who set the technical and philosophical tone for the project. The Linux kernel is a good example.
I am very worried about people using phrases like "mature process", "industry standard" etc. - in my experience, this often refers to the Rational Unified Process or the Software Engineering Institute's Capability Maturity Model. Both are laudable and when I go on holiday, I really want the airplane's control systems to be written using such processes. However, for many projects, the burden of bureaucracy is inappropriate (yes, I know you can tailor the RUP to suit your needs, but it contains over 140 different deliverables, none of which appears to be code). The training required to bring developers up to speed with these processes is significant, and usually expensive.
Instead, I'd look at the Agile methodologies at Agile Alliance website. The "Crystal" methodologies are especially interesting because they encourage you to actively choose the processes your project needs based on a variety of parameters - size, risk etc.
Having said that, I think a lot of the problems addressed are real - I think they get solved by people, not processes though.
I've never worked in a NOC, but I've been a customer with a couple of big names, and the most important thing to a customer is not the SLA - if we have to even read it, things have gone seriously wrong, and rather than litigate, we'll just leave.
The blinkenlights, CRM processes, trouble ticketing systems etc are all lovely, but the thing that makes a difference is the people. In one case, there were 2 network guys we spoke to - one was great, used his initiative to sort stuff out, never lied to us or tried to fob us off, and kept us in the loop with what was going on. The other guy was technically prob. better, but used all the company's processes to hide from us. He was reluctant to acknowledge problems, rarely responded to voice or email, and gave the impression we were not really important to him. They both worked to the same SLA, processes, standards, etc. One was good at his job, the other merely good at technology.
So, I would suggest that instead of spending a lot of time on SLAs, you spend time finding good people. Monitor your performance not by "uptime" (one of our suppliers was monitoring our site using the internal network. They got 99.999% uptime, while anyone outside the NOC got "server not found"), but by customer satisfaction - contact your customers once every 3-6 months and ask them to fill out a satisfaction survey. Deal with issues they raise. Treat a customer who leaves you like a company crisis. Encourage your people to think about outcomes, not processes.
Sure, you need to know how your network is performing, what your customer's uptime statistics are, and have the facilities we have come to expect (including blinkenlights). Just make sure you've also got some cat5, screwdrivers, and free drinks for your customers, and that you don't get carried away with all the fancy stuff.
When you can imagine querying the data you are entering - you can't easily query images, or other binary data (although I guess there must be someone working on this problem somewhere...). If you can't query it, you should usually find a better place to store it - NAS is usually fine - and maintain a pointer to it (e.g. a filename). Yes, it's something that can get un-synced, but most databases suck when it comes to actually dealing with binary data, and you can use that capacity a lot more effectively elsewhere.
When the structure of the data is likely to remain stable. If your application deals with well-understood entities, whose properties are unlikely to change over time, a database is a great solution.
Databases are, however, relatively change-resistant - it's typically a pain in the backside to change the datatype of a column, remove columns etc. So, if you're working in a domain where you continuously learn new things about your core entities, or if your development processes are highly iterative, you might be better off using an alternative data storage mechanism.
When more than a single user is likely to access the data - yes, you can create locking mechanisms yourself. You can also take your own garbage to the local dump. It's usually not a good use of your time, and the cost of not dealing with the issues involved are expensive, both for garbage and concurrent access to shared data.
When you require consistency accross transactions - the good old ACID (atomicity, consistency, isolation, durability) principles which become important for many non-trivial applications.
If you care about enforcing rules of referential integrity - do you want to ensure that all the tracks in your record collection can be tied back to a recording ? Do all orders have to have a customer ? Those things are far simpler to implement with an RDBMS than in code.
There are instances where using an RDBMS is not appropriate. Ones that spring to mind are :
- your business domain is not well understood or liable to rapid change. In this case, the cost of change for database objects is likely to be a problem - consider storing data in a self-describing format like XML.
- the application domain doesn't lend itself to being described in relational terms - image manipulation tools, word processors etc. which deal with mainly binary information probably should not use a relational model for their core data structures.
Alternatives exist - Object Oriented databases are becoming more and more popular. I have way too little experience with these to comment on their use.
you should definitely read up on this (though I am not aware of any first-rate books on managing customer support), and get a decent theoretical grounding in the subject.
However, I think most vendors emphasize the tools over the people using them. I'd suggest working on allowing the people working in your team to do the best work they possibly can do - protect them from corporate politics, establish a good relationship with whoever can fix actual problems you have to escalate, get them whatever tools they ask for, and make sure you have a decent working environment.
If you have to grow the team, make sure you hire the very best - ideally give the existing team a say in the process.
At the end of the day, the attitude of the person answering the phone is a lot more important to the customer than which trouble ticket system you use...
Or rather, not your only problem.
I have worked for a large, multi-national consulting firm (business as well as IT), and the key factor that made us succesful was that we established very clear measures to manage the sales and delivery processes.
Specifically, we changed the reward system for sales people so they were rewarded for the profit of the job, rather than the revenue. This meant that it was in their interest to avoid under-estimating the project, and ensured the sales team remained involved after the initial sale was completed. As they are usually the people with the relationship with the customer and the insight into their requirements; often, they're also better at negotiating the inevitable changes to the project as delivery progresses.
We also established a system for measuring profitability of assignments, and individual's constributions towards that profit (based on somewhat arbitrary but totally transparent rules); again, individuals (the entire assignment team, not just the sales team) were rewarded for their contribution to that profit.
The outcome was that we ended up with less failed assignments caused by under-bidding, and a happier relationship between the sales team and the delivery teams - the sales guys worked with the delivery team to protect their slice of the profit pie, and didn't disappear the minute the contract was signed. The sales guys concentrated on opportunities that offered significant opportunity for profit, and typically looked for longer assignments rather than placing a couple of people here and there just to get the revenue figures up.
You might want to read David Maister's "managing the professional service firm" - most of these ideas are documented in that book.
Once you have worked those issues out, look at development methodologies. I'd recommend Alastair Cockburn's Crystal methodologies which may be easier to sell than some of the more radical Agile methods. To do business with major clients, you will almost certainly want to look at the Rational Unified Process (RUP, www.rational.com), which is almost a "meta-process" - you choose the elements you choose from a range of processes, practices and deliverables.
A new kind of science - it's either genius or folly, but never is it boring...
Code complete by McConnell - very much about the practice, not so much about the theory, but still useful.
Software Engineering - a practitioners approach - useful overview.
Bentley's Programming Pearls - down n dirty.
just like code.
The reason latin helps me in my career - I took 6 years of Latin at a Dutch secondary school - is because it forces you to be extremely precise in the way you think. Modern languages allow a certain amount of ambiguity - English notoriously so - in the way you express yourself. Latin - like code - requires you to specify exactly what you mean.
The cool thing was that - after a few years - latin became second nature. It was no longer necessary to laboriously parse each word to make sense of the sentence, instead, the meaning started to become clear from the whole construct. I have found this to be the case with code as well - after a while, you no longer worry about the syntax of a given language, but rather move up a level to looking at the architecture as a whole.
Would I recommend Latin to anyone who has the option ? Only if you persevere. The first couple of years were tedious and frustrating; there's a lot of memorizing of stuff that appears to be complex for its own sake, and you have to work very hard to get even small results.
After you have the basics though, it becomes very rewarding - all western european languages become easier, the clarity of thought Latin brings with it pays handsome dividends, and we got to translate texts that were basically pornographic. There's nothing better than being 16 years old and having to translate porn for your homework. Oh, well, maybe there is....
The link with science and law is more about the absolute clarity of thought required than about the fact there's a bunch of words those disciplines borrowed or inherited from a dead language...
I went to a workshop he ran with Tim Lister and the Atlantic Systems Guild. Well worth the time and money.
Also check out "The Deadline" - a novel about project management. Really.
they had it easy. They never knew the pain of dealing with the falling value of stock options, not having the smartest car on the block, or falling behind in the gadget race. Maybe we should get a medal or sumthin
If you did - or bought something from an online retailer, or stored sensitive or valuable information stored on a computer that is connected to the internet....
There's definitely a lot of FUD sown by the "security" industry. I also agree that the media don't always treat the subject responsibly - events involving any kind of computer usually get cloaked in semi-accurate buzzwords implying the use of magical incantations and mysterious underground organisations, when usually it's a bored teenager trying to hack into a porn site.
On the other hand, there are serious security breaches every day - and script kiddies can do as much damage as a responsible hacker - more, because they often don't understand their tools very well. If nothing else, you need to protect your system against them.
If you write software that can be used by total strangers across the internet, you need to assume that some of them will have unpleasant motives and will attempt to cause your software harm. It doesn't matter if this applies to 0.001% - if you are dealing with sensitive data, providing a public service or rely on your income from your online application, if just one script kiddy brings your site down, you've lost the ball game.
I think anyone who is involved with online application development should at least look at books like this, and if you're the technical lead you should make sure you understand exactly what your application is going to be up against. The numbers don't matter - just one visitor is enough to do irreparable harm to your site.
as a techy, you have to consider what the real nature of your job is. Do you get paid for cranking out code/building servers/tuning networks/administering boxen/installing cool stuff ? Uh...no. You get paid to make things better in the company than they would otherwise be. I hate using the expression "adding value", but that's what it boils down to.
So, how do you make things better than they might otherwise be ? Being uber-competent at your specialisation is a good start, but being able to communicate and work as part of a team is usually even more important. So, when someone asks you something, just about the worst approach is "the moment their lips started to flap I could see they were monumentally stupid and deserved to be mocked behind their backs on some geeky web site". It's your job to make things better - that means listening to ideas from sources you wouldn't normally consider (your boss' boss), and treating their input with some respect.
And guess what ? If you take a little time to explore the idea with people, they can usually work out it isn't going to work. If you handle the conversation in a professional way, and show you're being thoughtful and thorough, after a few times you won't get the "I have to say something to justify my presence at this meeting" kind of input - people will start to trust your recommendations and plans.
Of course, you could just do the pained "that idea is so stupid I can't believe you tie your own shoe-laces" attitude thing, and you'll find the non-techies will fear and loathe you, and secretly delight in sending you on GFAR exercises.
You could not implement most of the GoF patterns in a language that doesn't support the core OO concepts ("Design Patterns for assembler" anyone ?).
Or rather, I would suggest that most if not all languages have un-documented patterns waiting to be published - but what works well in a java environment doesn't work in assembler and vice versa.
"A pattern is an idea that has been useful in one practical context and will probably be useful in others". (martin fowler).
Of course there are other definitions, but most include the word "context". The language in which you are approaching the problem is definintely part of that "context" - so I think there is definitely a place for an explanation of how to implement well-known patterns in a specific language.
Having said that, I think there's a trend towards "rip-off" pattern books which add too little value - I recently read "J2EE design patterns applied", which allegedly expands on the Core j2ee patterns book. It's not very good...
(for me).
After a project has gone "live", we maintain a bug-fix team for a short while to do the hand-holding. Once this team starts to look bored, the people get assigned to new projects.
Any new work is carefully analyzed - only critical bugs are fixed without delay. All non-critical bugs, feature requests, and other bits'n'pieces (documentation, testing for new platforms, end-user support etc.) is put into the great big "new work" pot. It's then prioritized alongside all the other stuff.
This forces the business guys to consciously trade work on existing software against new projects, and it avoids the situation where a developer is inundated with trivial bugs and/or feature requests - we found that many "bugs" were actually new features that nobody had thought about during the main development cycle. This is not necessarily a bad thing - many of the features were terrific ideas which added a lot of value. However, by forcing the business to trade off between those features and all the other stuff they wanted, developers can concentrate on the areas business had explicitly stated were the most important.
We also introduced the concept of "ideal days" in our project planning. This comes from eXtreme Programming and basically requires you to measure roughly what proportion of your time you spend on your "main" project; projects are planned using this ratio, so if we know that Joe can only contribute 30% "ideal" time to the project, we can plan accordingly. It's not a reflection on Joe - it might mean he's stuck maintaining someone else's sucky code - but it avoids squeezing Joe like a lemon.
The book "Planning eXtreme Programming" is very useful in this respect - you may want to get your boss to read it.
and I've rarely chosen the lowest price bid; money is never the sole criterion for awarding a project.
Here's an example : we were evaluating an e-commerce solution. I worked with the internal developers to get a feel for what the technical impact of the solution would be, what the interfaces back to the main system would involve, the sort of performance and scaling issues we would expect etc. All these issues were made clear to the companies bidding for the work.
I asked the vendors to address these issues in their proposals, and outline their ideas for how to deal with them, together with rough time estimates.
Anyone who came back with nothing more than a price (and yes, that happened with a couple of vendors) got put aside : if you're bidding for a job without understanding it, we're both going to end up in trouble. Any vendor who didn't demonstrate at least a basic understanding of the requirements in their proposal and did not submit meaningful estimates was asked to go back and think about it again.
In the end, we chose a solution that fell in the upper quartile of the price range; we spent a lot of time talking to the vendor, and everyone knew what the other was expecting.
What does this boil down to ? Yes, there are some PHB types who behave irrationally in the vendor selection process. There are also those who know from experience that a partnership has to be win-win. You have to make enough money on the job to be able to do it well, and help us out when the unexpected happens without having to renegotiate. We need to get a quality deliverable from you, and give you enough information up front to make a reasonable guess at how much time it's gonna take you. If you don't demonstrate you fully understand the requirement, and show how come you can do it for the price you quote, I'm going to assume you haven't thought it through, and are going to run into trouble delivering the job.
People who do this well (outside the big names) are perforce - they make it really easy to find out about their software, try it, and get comfortable with it.
jcorporate.com (home of the expresso framework for java development) are also pretty good - they have a decent mailing list and provide as much documentation as they can (though it appears they need some help there...).
Good luck
The big problem is that different people learn in different ways. Check out this description of the various polarities in preferences and how they affect the way people learn.
Personally, I have found the traditional "skill-based" training to be largely a waste of time - I just don't enjoy working through a bunch of exercises with canned explanations, esp. if the trainer is a professional trainer as opposed to a professional developer/manager/architect or whatever. The IT training business (certainly in the United Kingdom) is pretty much industrialized, and geared towards turning out as many Microsoft-certified whassnames as possible. Attending a course with one of the big training shops is in my experience a case of working through a bunch of thick books with more-or-less real world examples with doctrinaire solutions. There is rarely an opportunity to explore alternative solutions, and the goal seems to be acquiring a bit of paper saying "MS certified whassname" rather than learning anything new.
On the other hand, I have attended a bunch of excellent "training" events such as those run by the Atlantic Systems Guild which includes Tom DeMarco and Tim Lister, where there was an agenda of topics to discuss, but little or no "here's a book, read it, and we'll do a bunch of exercises" nonsense. The format was "here's an idea, or a story that happened to us once - let's consider what it means for you", along with a bunch of hands-on sessions exploring some of the topics.
So, all this comes down to - work out what your learning preferences are (there's a questionaire here, and make sure you tailor your training to it if at all possible.
though it seems to run out of resources at a few hundred concurrent users. You can find it at jakarta.apache.org. It's not very sophisticated, but it can certainly perform basic load testing.
I've also used (Mercury's) LoadRunner, a fairly expensive and complex beast; it comes with a built in proxy which allows you to capture a browsing session as the basis for a test scenario - this is a particularly useful feature. The scenarios can be scripted, and there's a bunch of random timers you can use to represent "real-world" behaviour.
I'd suggest creating 2 types of test scenarios : 1 type to represent your best guess at "real world" usage, i.e. representing users browsing, spending time reading a page, clicking all over the shop etc. - this should give you a good idea of how your application is going to perform.
The second type of test should provide you with metrics you can use when making improvements once you spot bottlenecks. They don't necessarily represent "real-world" activity, but allow you to measure whether code changes have made a difference. For example, you might have a test where all users log into the application simultaneously. In version 0.1 you can support 10 concurrent users; in version 0.5 100 concurrent users, and in version 1.0 250 users. These numbers don't represent "real" users - how likely are they to log in all at the same time ? It's a lot easier to manage your performance improvement work using these metrics.
than just a bunch of programming languages. Do you have experience of some particular kind of industry or an insight into how common business processes could be improved ? Do you have an idea for an application that you would use ? Are you a member of some as-yet under-marketed-to community with disposable income ? Have you been caught in some piece of customer service hell and thought "I know just how to improve this !" ?
Alternatively, are you masters of some arcane piece of technical knowledge ? Do you communicate well with other techies ? Have you read every single book and article on a particular topic ?
Basically, you need to find a niche. No company of any size is going to hire a 2-person shop - the risks are too high. What happens if one of you gets sick ? What happens if the project requires more resources than you can throw at it ? As a development manager who has frequently bought in help from outside, I would not want to have to hire "two guys who know C++" and then go to "mega-shop.inc" for all the other staff - one project, one supplier. Of course, there are always the smaller companies you can work for, but they often only have small jobs; you basically end up working a few weeks, spending 2 weeks looking for new work - the ratio of paid-for work to "marketing time" works against you. Small business are also often late with paying you for your work - not always consciously, but it's a major hassle you just don't need.
So, if you want to go into the professional services business, find something you can do which nobody else can do. Sell your ability to improve your customer's business for them, rather than your ability to crank out code. Pick a sector - "vertical market" as a previous post has mentioned, or technology (I know a couple of guys who have formed a "database designers guild"; they are well known as the go-to guys for complex database issues. They don't work all that much, but they charge very high rates when they do work).
Establish a reputation in that area - if you have to, offer your services "on approval", i.e. a trial period or something during which the customer can back out without paying you for any of your time. I'd suggest not working for free though - it's bad for your bottom line, but more importantly, most business buyers just don't respect or trust the "free offer" sales pitch, they fear getting tied into a vendor with very high costs later.
You almost certainly need to get a sales/marketing/business guy on board once you think you have a start. Techies don't make good sales people. You want to concentrate on delivering excellent work to your customers, not on sending out bills, making 20 or 30 sales calls a day, dealing with creditors and banks - it's not fun. Trust me on this.
Of course, if you look at yourselves honestly and say "we're just two guys who can code", you could still go for it and make all of us eat our words - Bill Gates and Paul Allen did it, so maybe you guys can too. I'd say the odds are against you - but it's your life. I'd suggest setting a bunch of targets and check points - something like "if we don't have our first client in 3 months, we'll quit. If we haven't been paid for our time in 5 months, we'll quit. If we haven't made enough to pay our bills in 9 months, we'll quit." etc.
Good luck. You'll need it.
We used it to
check out all the code for a given project and/or branch from the source code control system
check out all the relevant config files and putting them in the appropriate place
compile everything that needs to get compiled
Of course, by creating different build targets, we could make a bunch of decisions in the build process, e.g precisely which files to check out (live didn't get some of the debug stuff compiled in, so didn't need a bunch of support code), which config elements to check out, whether to enable debug features etc.
You still end up with multiple config files and all the mess that goes with it, but because the build process is totally automated, it is a lot less error prone. You can think of the ant build file as a meta-config file, identifying your environments and their specific requirements etc.
I believe there are similar tools available for other programming environments - you could do something similar with "make" if you really wanted to - and you could use ant for non-java projects if you want to invest a bit of time.
As a general principle, I always like to see build processes automated - it allows you to create environments without needing the skills of your company sociopath, it enables developers to find bugs in the finished product by re-creating it quickly, and when bad stuff happens, you can recover without too much panic - you know that your automated build scripts work reliably, and you don't have to remember that the database connection relies on some obscure library that you have to download from an extinct website somewhere.
Check out www.xprogramming.com for more on the importance of regular builds.
Or even mediocre managers ? The "team lead" role is the worst position to be in - you have a whole load of resposibility, and almost no authority.
I'm guessing you haven't got the authority to fire your team (and I don't think it's the right solution anyway), hire more team members (ditto), change the scope of the project (this is more likely to yield results), or change the way you're working (bingo ! give the man a cigar !). You can't exert much formal control over the team, and you have to be careful with running to the senior management team, because they usually don't like to hear bad news.
So, I would suggest that you get the team together to do a semi-formal project assessment, compare actual to plan, that sort of thing. If things are as bad as you say they are, the team will likely recognize this; you can then declare an official "state of emergency" - note that you should do this without involving the managers at this stage. Suggest that you all spend a couple of hours brainstorming ways to get the project back on track.
Sneakily, look into eXtreme Programming and / or Scrum - there are a couple of easily digest books available on both methodologies from your favourite patent owner.
I would suggest that in the brainstorm meeting, you steer the discussion towards ensuring progress visibility is the key priority. If the project is in trouble, you need to know how badly, what the backlog is, and what your current estimated delivery date is - it's the only way to measure your progress. This can be as simple as a spreadsheet on a file server with tasks and status (hint : accept only binary completeness indicators - otherwise you end up with lots of projects at "90% complete" status which turns out to be 30%. A task is complete or incomplete - final).
I would also suggest revisiting the original plan. I have found that it is usually better to allow people to make their own estimates and prioritisations, so ask everyone to adjust the estimates and dependencies, see where you're at - if you're gonna slip, find out today, rather than 2 days before shipping.
Next, you might want to discuss introducing iterations, ie complete, running, shippable software implementing one or more new features into the product. I've never worked on embedded products, so this may not work in your environment, but it really helps to improve the visibility of your progress when you know that you'll be delivering a complete application every 4 weeks or so. If you promise management/the customer/your mom to do a demo, it helps even more. It also ensures you don't have any last minute bugs to deal with on shipping day.
Work out - with the team - what you're going to do, and then do it. Don't tell anyone until you know it's gonna work. Make sure you stick with the changes, and enforce them. Review the situation after a week or 2; tune, repeat. If you find you're in such deep trouble you can't see a way to fix it, tell your boss the moment you know for certain you can't recover.
There are no magic bullets; stuff I can pretty much guarantee won't work are adding more people to the project (except if you have an exceptionally well-defined design and a lot of repetitive drudge-work to do). Bullying people and threatening to fire them is a surefire way to get them to spend their time honeing their curriculum vitae and surfing the job sites. Stuff that usually helps but may not be enough is improving visibility of project status, increasing the level of detail in the plan to binary 1-3 day tasks, and increasing the team's level of ownership of the plan.
Welcome to management. Coding's more fun.
Seriously, I doubt that cross-platform capabilities will be a huge issue (a previous post claimed that most serious contenders are cross-platform or at least web based - I reckon it's true...).
In my experience, these beasts come in 2 rough flavours : the "database with a front end" flavour at around the 500 USD mark, and the "help desk, ticketing, workflow, knowledgemanagement, coffee preparation and universe rescuing" flavour, at a price you only find out from the leather-bound ring binder of a fragrant sales representative.
If your company is going for the cheap flavour - pick one, learn to live with it. It will almost certainly not be quite right for you, but you should be able to make it do what you want.
If your company is going for the all-singing, all-dancing flavour, seriously consider whether you need it, and whether it would not be cheaper, easier and less painful to take that wad of currency and insert it into various bodily orifices.
Here's what I have found to be the case : regardless of the promises of the venduh, it will be expensive and difficult to customize the product to meet your needs; you are likely to end up with a kludge.
The "value-added" components will cause more trouble than they solve - I have especially fond memories of an automated inventory application which didn't recognize my ergonomic keyboard and automatically raised helpdesk tickets for the support team to bring me a new keyboard; they religiously turned up every day for about 2 weeks with a newly ordered keyboard...doh.
The more politically active managers will use the data produced by the system to "prove" that one department or another is more expensive/productive/careless/likely to break company policy/set fire to the building than another. The better the reports from the helpdesk system, the more bitter the political battles.
The automatic email reminders will be forwarded to everybody's trash folder because of the false positives; of course, the vital real business-critical problem will not be spotted until the hard drive of the chief exec has been filled with pictures of britney spears, a chicken, and 3 gallons of maple syrup.
In short - with these things, I tend to feel that just a little less than enough is usually more than sufficient. It's a great way to waste enormous amounts of time, money, and credibility when you could be doing stuff for your customers.
As someone else has already mentioned, the process you describe is not strictly speaking regression testing.
I have worked on quite a large number of software projects, and every single one included "testing". The level to which software is tested, however, varies widely. One project I worked on was a billing application which collected the entire company's annual revenue. Yep, we tested that one pretty rigorously....But I've also worked on web site projects where the downside of getting it wrong was not so severe; we tested almost as an afterthought.
There are a lot of test "gurus", and a bunch of different methodologies to provide a testing framework. Checkout testing.com to get a feel for this...
It all boils down to the decision how much time do you spend on testing versus other quality assurance methods. Testing is the most expensive and least effective way of finding bugs except for releasing the code to your customers. Practices such as specification, design and code reviews, design-by-contract, aspect-based programming give you far more bang for your buck.
FWIW, on the billing project, we had a formal specification review to make sure that the product we built did what the business needed, a business representative to help fill in the blanks in the specification, a design review to make sure that the software we intended to build was indeed what the spefication asked for, and made sense in its own right. We produced numerous prototypes and mock-ups to get our customers to tell us we were on the right or wrong track without having to learn to read software design documents.
During the code phase, we created unit and integration tests which measured the kinds of thing you mention (e.g. order total must equal sum of order lines), and had a dedicated test resource. We ran code reviews. We also made sure we showed the work in progress to our business sponsors as often as we could.
When we thought we were done, we had a formal show-n-tell to present our work to the business; this lead to a bunch of rework, which again was tested, reviewed etc.
The software was succesful from the business point of view; with hindsight, I'd say that the code was truely awful, and I wish we'd spent more time on code reviews. How important was testing in the QA process ? It provided a useful yardstick to tell us how close we were to meeting our objectives. Would I have relied on testing without all the other stuff - reviews, prototypes, great access to the business folk ? Hell no - if you don't know that what you're testing is what the customer wants, your tests are pretty much valueless.
So, I guess I distrust any organisation that over-emphasizes testing as a QA process - there are better ways of avoiding bugs. On the other hand, you have to provide the appropriate level of testing - if you're writing nuclear missile guidance systems, you need to allocate a lot more resources to testing than if you're building a website to hail your cats' achievements as politicians.
Ne