As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I want to be able to choose the right branching strategy for most thinkable situations and organizations. So I'm looking for a extensive list of positive and negative effects of extending the use of code repository branches in a development organization.
Please only post one pro or one con in each post, so that the voting system can help rank the feedback somewhat.
Pro: By keeping latest deployed version in trunk, small fixes can be rolled out quickly without extensive testing of the latest development version.
Pro: Developers can work more freely in tighter iterations without stepping on eachother's feet.
Pro: if you have many branches you'll be pushed to adopt a modern DVCS (my experience is with Mercurial but I hear git or Bazaar are also good) rather than stay with a traditional centralized system (like, say, svn).
Pro: Branches can be used to facilitate 'what-if' scenario's in trying out new code. At the end a decision can be made to merge the new feature or to abandon it.
Con: Having too many branches in the air at the same time and you start forgetting where things where commited, where changes have been made etc.
Con (and it can be a big one): Merging back at a point in the future. The longer the duration and the greater the deviation of code base, the harder your life will be. My advice: think very carefully about branching and ensure you only do it when necessary and consider the effort involved in merging at a later date should it be required.
Con: Merge nightmare.
Con: Greater learning threshold for junior developers.
Pro: Each update is independant from the others, so work can be parallelized.
Con: someone has to manage the branch(es) and keep on top of things. In most teams this falls by the way-side.
Pro: Greater flexibility in diverging code for the purpose of simultaneously developing on or supporting multiple streams of work.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a bunch of C code accessing database (Oracle, DB2 and Sybase) through Embedded SQL : the base code is the same, but with three different precompilers, three sort of executables are built, one for each database/platform.
I works perfectly fine, but we need now migrate to a solution using ODBC access.
The problem is : what tools / api can be used ? A direct way seems to write a custom precompiler (or modify an existent) to wrap all SQL and host variables calls to calls on an ODBC connection.
Can somebody recommend tools for that task or api to keep it simple ?
Or is it a simpler way, another approach ?
Thank you
As is usual for such situations, there are likely no off shelf answers; people's codebases always have a number of surprise in them, and the combination prevents a COTs tool from ever being economical for individual situations.
What you want is a program transformation system (PTS), with a C front end, that can be customized to parse embedded SQL. Such tools can apply source-to-source rewrite rules ("if you see this pattern, then replace it by that pattern") to solve the problem.
These tools require some pretty technical effort to configure. In your case, you'd have to adjust a C front end to handle embedded SQL; that's typically not in C parsers. (How is it that you can process this stuff in its current form?) You'll have trouble with the C preprocessor, because people do abusive things with it that really violate a parsers nested-structures-view of the universe. Then you'll have to write and test the rules.
This effort is a sunk cost to be traded against the effort of doing the work by hand or some more ad hoc scripting (e.g., Perl) that partially does the job leaving you to clean it up. Our experience is that it is not worth the trouble below 100K SLOC, and that you have no chance of manual/ad hoc remediation above 1M SLOC, and in between your mileage will vary.
At these intermediate sizes, you can agonize over the tradeoffs; that costs energy and time, too. Sometimes its just better to bite the bullet and do it any way you can an clean it up.
Our DMS Software Reengineering Toolkit is one of these PTS. It has a customizable C parser and preprocessor, precisely to help deal with these configuration troubles. The other PTSs mentioned in the Wikipedia article, do not, I beleive, have any serious C parser associated with them. (I'm the guy behind DMS).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have been working on an application from past 4 months and it's very much depends on Google Maps on iOS platform. Recently one of my friends raised a concern that what if Apple Inc. decides to use a different Map provider?
It turns out after few searching on internet that Apple is going to replace Google Maps with some new advance 3D maps build by company called C3. (One of the researched resource). Well now I am worried of my already written code,
Should I delay my development work until this new technology gets in? or just wait until Apple announces officially.
Thanks
This is a common dilemma in programming, and there's a common solution too. Develop your own primitives - whether you need to display overlays, show landmarks, draw polygons and lines, do everything through stubs in your own code. If the underlying platform has to change, you then have a few well-known places to update to the new API.
Be very strict about not accessing the underlying API anywhere that isn't in your wrapper layer, and it should be straight-forward to change to a different later. Not free, of course, but so long as it's possible to implement the primitives you need in the new layer, you just need to change those, and can leave the rest of your project untouched.
It's not worth losing months' of having a finished project to avoid this situation.
Edit: This approach has another benefit - if you end up writing multiple primitive layers for different APIs, you may be able to let the user pick between them: you may have a (more expensive) higher-quality map layer which you charge for, and a cheap/free one which you don't - allowing people free access to a lower-quality version, and letting them buy an upgrade to the better maps. Or ... there are lots of possibilities. It's the same pattern some applications take with data-persistence layers, letting people run the same application on top of differing data platforms. There are lots of examples of this patterm.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
The advantages of ORM are pretty clear. But I noticed that some companies prefer to build their own home made ORM. Why?
There are only two arguments that I can possibly see for ever hand-rolling your ORM (and these have happened to me in the past, which forced me to write my own):
The company refuses to use Open Source software because of liabilities they assume might creep into their application.
The company refuses to spend money on a commercial ORM.
Any other argument (like the quality of Entity Framework is too poor for us to use it) is completely moot. No matter how bad Entity Framework (or whatever other ORM you may be referring to) is, you're not going to come close to the robustness and reliability by hand rolling your own.
As O/R mappers are very complex pieces of software, writing your own which goes beyond the typical datareader wrapper and pre-fab SQL query executor will take a lot of time (think 6+ months full time at least). That's not the biggest problem. The biggest problem is that once you go with your own O/R mapper, you have to maintain it for the rest of the time the application using it is in production. Which can be a long time. Make no mistake, maintaining an O/R mapper yourself is not a simple task: you have to re-invent every trick O/R mapper developers already know about and have solved themselves.
Last but not least: doing this yourself should not be done on a billable contract. After all, you're writing infrastructure code which is already available elsewhere.
I know I'm biased (I wrote LLBLGen Pro), but I also am one of the few people in this industry who has written a full O/R mapper framework and knows what it takes to get a decent one up and running with good performance and a great feature set.
Simply do the math: if it takes 1000$ to get an o/r mapper framework license (or less) and you can get started right away with the application of your customer, how many hours do you get for that 1000$ so you can built the O/R mapper without costing the company any money? And maintain it? No way you can do it for that money.
If you have an in-house database that has evolved to have a bad schema, it can be simpler to write your own ORM layer than try and get an out of the box solution to play nice with it.
In my opinion, ORMs are specialized and purposed to solve typical problems. If you want some more generic solution (e.g. for much more complex queries) or just different functionality you can either modify existing solution (what for various reasons often isn't the best choice) or create your own.
ORMs also limit you by forcing you to use their conventions and accept their limitations.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Do you primarily think of reasons TO implement it, or reasons NOT TO implement it? What are the advantages of each?
This fine Joel Spolsky post basically says:
Make a list of possible features.
Vote to filter out the worst features.
Assign a cost for each feature.
Allot a limited feature budget to each participant.
Find out which features are popular when allocating the budgets.
I usually do a cost benefit analysis. How much is this going to cost to implement (in money or time) and how much is the benefit worth (again money or time).
If the benefits outweigh the costs by enough of a margin, it gets done.
The measure is usually money for paid work, time for personal stuff although there's sometimes a crossover. I won't sacrifice too much quality time with the kids no matter how much money's on the table.
I think first about the stakeholder (the client).
Will that feature help him ? Is it indeed a functional feature that brings value?
Then I think about technical implications and the resulting complexity, in order to evaluate the trade off between implementation cost vs. not having that feature.
Based on those two first elements of reflexions, I can begin to know if I must implement it or not.
I guess there is no clear cut between reasons to or not not implement it.
I think that it is important to consider both pros and cons, with the end result being a cost benefit analysis.
The landscape of that analysis can shift a lot depending on the sort of product the new feature is proposed for. A lot of my work is on big complicated applications that have evolved over time and are core to the business of my customers.
Consequently a lot of analysis of a new feature focuses on why not to implement a feature; I will largely concentrate on risk:
How well architected is the area where the new feature is to be introduced?
What is the level of unit testing already implemented?
Is the new feature being implemented right at the heart of the application?
What happens if we miss something and a bug gets out into the wild, could it bring the system down (either literally or by effectively making the system unfit for its purpose)
At the end of the day, it is the customer's decision on whether or not a new feature is devloped. As professional software developers it is our responsibility to inform them of possible costs that may not be visible to them beyond the bare dollars and time.
The happy flip side is that we also have the responsibility to propose new features that they may not have thought even possible!
A lot of the time we're asked to put in a certain feature. Part of my job is being able to interpret this in the context of users who think they know what to include all the time. Sure, they know what they want, but you can bet someone else wants something slightly different. Its important in my world that we can think one step ahead and deliver more. We're paid to think how the business works and provide for them.
Thus, i come up with the strategy of adding something a bit more powerful, and then also delivering what the user wants as well. Thus, when someone else asks for something, its already there. This can save a lot on costly delivery cycles.
Unfortunately, this is not always available or practical, but if possible, i like to do it. I like to run with the motto that coding should be proactive rather than reactive.
The customer gets to decide on features. If I think of something I run it by the customer. Together we figure out how to get the customer's most important features implemented soonest.
Fantasy decision-making question: Does feature improve product's ability to do what it is particularly suited to do? If yes, implement feature, else don't.
Reality decision-making question: Do we have enough money to justify implementing feature? No? Crap.
It should be the client/customer/stakeholder/consumer that should drive what feature needs to be there. The client can be a real world user (single company or individual you are delivering) or not (a market you are making a product for). But either way, it has to come from an end-user.
We call all our new features "user stories".
What you certainly need to do is to understand why the user wants that feature - what is the problem that the user is trying to solve or advantage it wants to gain. You need to get the 'why' part from the user before you get to 'how'.
Implement a feature if it will help the user complete a certain quicker or complete it with more knowledge. If it will help the user, implement it, if it makes your app look better but doesn't really help the user around the application (just looks good) then don't implement it.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Over the years, I have tried many times to find a good, easy to use, cross platform tool for some basic software system diagramming. The UML tools I have tried seemed to get in my way more than help. So far, the solution I keep returning to is Visio, which is both Windows-only and expensive. Although its far from ideal, it does provide some basic building block and allows things like grid placement and zooming. I wanted to see if there is a great tool out there that I'm just missing that fits at least some of the criteria mentioned.
Graphviz FTW!
What could be more hardcore than writing a text file to convert into a diagram etc...
GUI, we don't need no stinkin' GUI!
You could try DIA, though it is a bit basic it will keep out of your way when doing pure diagrams.
http://www.gnome.org/projects/dia/
Well, I guess you mean for Windows. Otherwise for the Mac, nothing I know can beat OmniGraffle. Not only it is so easy my grandmother could use it, it can actually make really "beautiful" diagrams. It is really not too expensive (version 5 is now $99, but older ones used to be less than $40; still got a cheap one) and it can do it all, network diagrams, flow charts, UML digrams, UI mockups, etc. The app is clever, it thinks for you in a way, e.g. it will detect that you try to align objects on a line or have equal spaces between them and offer you hinted drag'n drop to make sure these criteria are met. As I said, it's really easy to work with OG.
And it can even also existing Xcode project (the standard Mac IDE for programmers) and automatically generate graphs from your source code. A complete UML chart by just pulling your Xcode project onto the icon :-) I guess it would be great if they could port that to Linux or Windows, but I'm afraid it will never happen.
Enterprise Architect (http://sparxsystems.com) is the best and very affordable.
I've used Edge Diagrammer... It does what you want simply and quickly. Supports grid placement and zooming. It's Windows-only, and it's gotten more expensive than I remember, but still cheaper than Visio.
I like Visio
If you have to use software, Visio is my favorite. (I get it for free through my school's CS program)
But... I find the best tool out there is a 17" x 11" sketchpad, sure it's made for artists but nothing beats a massive piece of paper for figuring out design problems.
The most productive diagramming, in my experience, is done on the whiteboard.
I capture in Visio, though, it has more tools and shapes than anyone else, and you can extend it to do code generation.
Sometimes I use yEd. It is a Graph Editor, but it is perfectly able to be used as a diagramming tool.
MagicDraw is quite good IMHO.
The best free solution that I'm aware of is Dia. It's marketed as a casual Visio replacement.
There's also Kivio, which I've heard good things about but haven't personally used. That one's multi-platform and free.
I use Violet UML Editor for most of my diagrams. It's not cluttered with code reverse engineering and code generation features and makes creating elegant simple diagrams very easy. Best of all it's free.
TopCased http://www.topcased.org/index.php
BOUML: http://bouml.free.fr/index.html