Tag Info

Hot answers tagged

68

If they really are reusable methods / classes, you could write them into a small number of 'Swiss Army Knife' libraries. We do this quite often at my company; we call them framework libraries: Framework.Data - Utilities for working with database queries. Framework.ESB - Standard methods for interacting with our enterprise service bus Framework.Logging - ...


33

Change. Especially, unmanaged, uncontrolled change are a huge risk. You can embrace or control change but don't ignore it. Edit: Extended answer with example (as the OP asked for one) As I said in the comments, software is abstract, especially to people who don’t work writing it. With something physical it is easy to see the progress and barriers to ...


19

Assumptions are the biggest risk. You assume that you know what your team is doing. You assume that your team knows what they are doing. You assume that your team would tell you if they no longer know what they are doing. You assume that you're doing what the customer asked for. You assume that what the customer asked for is what the customer wants. You ...


17

What you suggest is fine from the point of view of the Systems Engineering purists. (There will be a few Agile devotees who think its all way overt the top... and you should just get out and do stuff with the usual reviews, etc). However, you need to take into account what you are doing, and who you are doing it for. Doing a project for yourself is ...


14

I disagree with the accepted answer for many reasons. In my experience, when I see "miscellaneous" libraries like the accepted answer, they're an excuse to reinvent the wheel (or not invented here(NIH)) - a far greater sin than violating Dont Repeat Yourself (DRY). Sometimes violating DRY can be a reasonable compromise, it is better than introducing tight ...


12

You need to keep a close eye on your dependencies on third-party components, particularly if they are specialized ones that may have very few other users who are doing exactly what you are doing, and that may be difficult or impossible to replace. If there are any bugs or gaps in the features you need for your system, you will be at the mercy of the ...


11

Since this could be a long ongoing project, I want to get the structure right from the beginning It's pretty tricky to know up front what the correct structure for a collection of code should be, especially where the project is essentially an R&D effort (for which read: you haven't personally built such a system before1). So don't bother; instead, ...


11

I'm not sure if the customer really "made a mistake": They had a solution which started with a very small initial investment, which could be maintained in-house, which grew together with their reqirements and which just worked. If the current solution "works for the scope now", the argument that Access is completely unsuitable for a project of that scope ...


10

Failed software projects are almost always the result of programmers and managers who don't know what they're doing.


10

Organizations that treat talent (not just programmers) as resources that can be swapped in based on job title. This is really quite common, although it's almost never as 'coarse' as my description. The common manifestation is: We're running late, if we add these 5 guys who have never even seen this project, I'm sure we can pull it off! Orgs that think it ...


9

People & Communication The programmers need to be able to program. The analysts need to be able to communicate to the customer in a way that pulls out what the customer really needs. Then the analysts need to be able to clearly communicate this to the programmer.


9

There can be many reasons why the client prefer Java over Python/Ruby. Here are a few: 1. There are more Java programmers than Python/Ruby programmers out there. If they ever want to take development elsewhere it will be easier to find Java developers. 2. The client already have most of it's software written in Java. If they ever decide to get their own ...


9

Blender was initially commercial. Update: this answer is far better than mine; upvote it instead.


8

New, new to us, and known technologies used in new ways. You can minimize these risks by doing proof of concepts apps in the design phase. These small projects will also serve as a communication tool in the future on how something should be done.


8

anything you don't understand is a risk factor; this includes things that aren't specified well and things you've never done before and things with insufficient documentation etc. mitigate the risks by planning for and doing - up front - investigation and prototyping (a "spike" project in XP terms) be prepared with a fallback plan if the initial direction ...


8

except for the fact that it would alter properties and input variables to functions/voids inside the Business Logic class to provide a different set of data for another completely different user That's just a design mistake. Nothing more. Fix it first. Then simply share the business logic between the two web applications. Should we maintain two ...


8

I have never been a fan of including existing projects that belong to other solutions. There are too many variables where making an edit to that project for 1 solution completely breaks something in another solution. Then by fixing that problem you end up breaking the original solution. Lather, rinse, repeat. When this kind of dependency leaks into multiple ...


8

I think the list should include: The non-technical requirements (there was such a document, right?) The technical requirements A "decisions" document (if there was one) explaining why some decisions were made over others. This might already be in a different requirements or architecture document, but we usually do this separately for Big Decisions. The ...


8

Some "Formerly Commercial-Only" Projects The IntelliJ IDE was originally closed-source A lot of Id Software games, old (like Wolfenstein 3D) and not so old (like Doom 3) A lot of projects released as open-source by Sun Microsystems started as closed-source experiments or products: the JDK and JRE themselves, NetBeans (interesting crossing history lines ...


7

Thinking that you gathered all requirements and being sure the client told you everything you need to know.


7

It is 100% OK that your customer (in this case your Dad) doesn't want to bother with interviews to gather requirements as interviewing is but one method useful for requirements elicitation. A few methods immediately come to my mind in this situation. If it were me, I'd probably pick and choose pieces of each of these to figure things out. ARM - ...


7

Some people use Maven or similar solutions that automatically download libraries from various repositories as needed. It may be convenient, but then you're dependent on repositories maintained by some 3rd party. Getting some less popular libraries updated may be sluggish, and of course, most commercial libraries aren't available in public repositories. ...


7

Qt was originally a commercial project by Trolltech, then when they were bought by Nokia it was released as a dual (commercial/LGPL) project. The value to Nokia of having it as the default GUI toolkit of programmers all over the world was more valuable than the extra license fees from a few commercial customers ( or it would have been if Nokia could ...


7

Stick with one TFS Team Project, having multiple becomes a pain when trying to upgrade and has some limitations when it comes to cross team project work items. Instead you should be making heavy use of Areas and Iterations. Split your VS Solution into multiple solutions, one per major application. This will speed up local builds a lot, as well as the ...


7

For small bits of code -- say a single class with no dependencies -- we tend to just copy and paste the code into projects. This sounds like a violation of DRY, and I'll admit it can be at times. But over the long term it has been much better than having some sort of massive, multi-headed commons project for a few reasons. First, it is just simpler to have ...


7

One product, one source code, different data. There are not really enough details to know whether my answer is the right one, but your problem is a common one for solution providers with multiple customers who have slightly different requirements. The answers always some to converge on: Just One Product. When you build, you build everything and when you ...


6

You want to create BLL, DAL and BASE as Class Library projects. You should ensure that no UI logic is included inside these projects, as you want them to be independant from the type of application you want to develop. Then create your presentation layer as a Windows Forms or a Web Application (or both!) and add references to your class libraries. However, ...


6

It depends... its all about dependency management. You're going to have a lot easier time with a single solution. This is so you can simply reference the other projects within a project and it'll all build and will be up to date everytime. This approach doesn't scale though. So the problem is entirely down to those pesky references. The biggest problem I ...



Only top voted, non community-wiki answers of a minimum length are eligible