Fog Creek Software
Discussion Board




Interview Question

What three issues would you consider being the most important in a long term, n-tier, enterprise solution development effor and why?

Thought to get your thought on that.

relevated
Saturday, September 07, 2002

What exactly would you consider an "Enterprise solution development effort"?

First step would be to drop the term "solution" until you have a real problem to solve.

Joe AA
Saturday, September 07, 2002

I agree with the other guy:  First tell me what the problem is then we can come up with a solution, not the other way around.

Off the top of my head:
Reliability:  It should be reliable and available 24/7.  You can accomplish this by creating high quality code with error detection and network redundancy (think Google)

Scalability:  It must scale as the number of users connect to the system.  This also includes Databases, Disk Arrays, Business Components.

Maintainability/Extensibility:  Components of the system should be fairly loosely-coupled to reduce dependencies of one component on another.  Also the system should be able to be extended easily. 

Tim
Saturday, September 07, 2002

The most important "thing", in my opinion, is having a team of skill developers who understand what they are trying to achieve and have the ability to think creatively.

Walter Rumsby
Sunday, September 08, 2002

Sure, having good people is always good... but needing developers at the offset is also a good way to fail by implementing the solution before you know the problem.

As the first three steps, I would leave out all aspects of technology.  Because if those first three aren't solved and maintained throughout the project, then the project has a good chance of failure.

The second thing is to make sure the enterprise really wants to solve the problem... once it has been defined.  Solving a problem that no one wants solved, is definitely a path to failure.  Don't count on the "CEO" or CTO or whatever C level TLA you want to mention being able to "demand" it of the organization.  If you are in for a fight you better know it up front, and the larger the organization the greater fight it will put up to avoid change.

The third has been proposed many times, but very few projects pay it much attention.  It is sometimes stated as making sure you are solving the right problem, but is often put forth as a recommendation to "reengineer" the business process before implementing it.  Introducing automation into a kludge business process that has evolved over time, is the third path to failure.

A possible fourth concern would be to make sure any advances in the first three don't disappear when the development team disappears to do development.  If you have not maintained the first three, when you come back with your brand new shiny "solution"... then all promises and assurances may have been forgotten.

Joe AA
Sunday, September 08, 2002

Back to basics.

1. How useful is it to the customer?

2. How much does it cost the customer (including consulting, etc.) to use?

3. How easy is it for the vendor to maintain it?

Everything else follows from these.

Paul Brinkley
Monday, September 09, 2002

I'd say time, budget, and requirements might be important, heh.

Development environment/process is important, I find that this is where efforts usually fail to meet the end goal, whether it be because lack of quality control, lack of daily builds, lack of proper requirements gathering, etc.. Get the process going up front and tweak it as you go to meet your needs.

Also, making sure the proper channels of communication are open is essential. I've failed on this particular item and it bit me in the ass. I had to learn the hard way that communication between developers and stake holders is not to be taken lightly and needs to be honest and up front so no one is surprised when things change.

trollbooth
Monday, September 09, 2002

I'd say a mixture of the above posts, but summarised as: people, people, people. You can't beat having the best you can get. Whether it's defining the need,  the requirements or building it. Also, the closer you can get them -- communicating, talking, designing -- all phases the better the outcome, even if the outcome is that you don't need the system built.

kendes
Thursday, September 12, 2002

*  Recent Topics

*  Fog Creek Home