89

There's a famous military saying, attributed to Helmut von Moltke: "No battle plan survives contact with the enemy". In the same vein, I do not think it's possible to make a spec that will not have to be changed - not unless you can predict the future and read minds of the stakeholders (even then they may not have yet made their minds, even if they claim ...


71

I'll start with the hard truth: If your business model only works as long as you can get an expensive resource (developer talent) for a price lower than the market price, then you don't have a business model. The fact that you're competing against larger companies isn't an excuse. In the development field, larger organizations typically have higher costs per ...


40

Deliver something (I hesitate to use the word anything) early and deliver often. That is - use some sort of iterative development methodology. This is the basis of Agile development, but can be used with (almost) any methodology. By breaking the project down into a series of mini projects you get more control as you can put something in front of the client ...


40

You are approaching this from the wrong side. In most companies, management is not responsible for "choosing the programming paradigm", they are (or at least should be) responsible for making the team work efficient. If your whole team is convinced functional programming will improve the speed or quality of your work, it should not be too hard to convince ...


37

Computers are not physical monolithical entities anymore, use virtual machines ! Your developers should be able to access different work environments as they need, and virtual machines are the perfect way to do so, you can : keep a legacy environnement easily accessible. have multiple, independent environments (ex: 1 environment per client) have test ...


30

You need to think outside the cubicle. Take advantage of your flexibility. If you want to hire a top talent programmer, but can't pay a full salary... hire a part-time, top talent programmer. You'd be surprised how many people would jump at a 20 or 30 hr/week job, so long as the hourly rate you were paying them was in line with what they'd be expecting. ...


26

You can try to get new grads who are desperate for a job willing to put up with less pay for the experience. But you will have to have a really good eye to pick out the undervalued person with high potential from the majority of them who are just plain bad. The problem is even if you get the undervalued person who are really good, you shouldn't expect them ...


23

Your software is maintainable. That is why you are working on it. In fact, the revenue they get from selling and supporting that software probably supports your loaded salary. If I was managing something that works, I would leave it alone. If you had a house with a convoluted plumbing architecture, would you pay a plumber to clean up the architecture even ...


22

The theory that it is possible to completely spec out a software project of any significant size is a complete fantasy. This theory has been found not to work in organizations from large to small for pretty much the entire history of software development. You MUST find some way to accommodate changes as you go! They ARE going to happen, because most of the ...


21

Unfortunately what they're doing is "putting all of their eggs in one basket". Working with an outside firm is quite likely to provide revenue for them, but I seriously doubt that it'll be worth the money. Documentation always looks nice and clear when you write it. The problem is that you only know how much it's worth when somebody else tries to read it - ...


21

I think you've reached the point where you need in infusion of capital in order to grow. Your question should not be how you can get inexpensive developers, but how you can get the capital to pay good ones. This means you need to evaluate your business plan to determine whether the investment in developers will return more value than cost in a year or ...


19

Don't try to prevent change, embrace it. The more you plan ahead, the more likely your plan will change. So, plan less, not more. Adopt an agile development methodology where you deliver small chunks of working code frequently, giving the customer the chance to change the specifications every couple of weeks.


19

is it a danger if the developer does not have experience with the underlying technologies? Yes. (Learning takes time, and making mistakes is often part of the process.) or can a general developer who is accomplished in another area realistically pick up new technologies? Yes. (Picking up new technologies is something that generalists do all the time. ...


18

Paid support really works best for those things that are specific to your product that will benefit from your expertise. If you are a domain expert in your own product, you are the one best qualified to be a top-notch consultant for your users. Nobody wants to pay good money for run-of-the-mill customer service or for things that I would call "common ...


16

I think you just need two things: The Dream and the Balls to just do it. As for timing, don't quit until you have the money to quit.


16

If you want to build trust I suggest that you not ask us, instead ask the people that consume your alerts. Now is a great time to bring it up. Briefly explain the situation and ask if they think the alert should have been sent out as it was or not. Asking for and acting on user feedback is a great way to get the correct answer for your situation and build ...


16

Bill! Seriously though "consultancy" is a very vague term and can cover many things. At one extreme are low level body shops which hire fresh graduates at $250 dollars a day and farm them out to large corporations at $1500 dollars a day. The lack of experience is regarded as a good thing as they take longer to get the job done, their work needs more ...


16

Windows 8 isn't even commercially available yet. If you upgrade now, it might be to a beta of questionable stability with features that may or may not make the final cut. If you can afford it: set up an isolated test developer machine and upgrade that one. Then let all the developers play with it now and then to get used to it and find all the little ...


16

Don't let it stop you, but don't build it for yourself either. There are very difficult and extreme restrictions on PCI compliance, which is the technical hoop you have to jump through to store credit card information. Do yourself a big favor and use a service like Authorize.net or Stripe that lets you store all of that sensitive data on their servers and ...


16

To understand why Functional Programming hasn't taken over the world, you have to understand the corporate thinking behind programming language decisions. To pick on Java for a moment: There are armies of programmers available that can write reams of ordinary Java code. This is not true of Lisp or Haskell (or even Scala) programmers. Everyone else is ...


15

There's a good possiblity that your firm could significantly change financial market making by releasing the source code. Having mulled through the idea, I have to agree that the pros outweigh the cons. For what it's worth, I'm fairly familar with market structure. I interviewed with an exchange to join their IT staff. It wasn't a good fit and I didn't ...


14

Personally I would not work anywhere that I didn't have the opportunity for direct client contact. Trying to resolve an issue with the requirements when you have to go through layers of PMs and BAs is painful and the message never gets through clearly. I want this access to improve the product so that it actually reflects the clients needs and not the ...


14

Read Joel on Software - Things You Should Never Do, Part I, or hope you managers don't. Mine obviously had not read it, I bet now, if they have, they wish they had earlier..... I work on a project rewritten in Java from over a million lines of legacy ADA codebase. We now have less than a million lines of new "Java syntax" legacy Ada program, with a whole ...


13

There are some dangers with ad-hoc reporting. Reports tend to proliferate in the resulting combinatorial explosion. any report so-created has some built-in legitimacy because, well, it is a printed report, so the information must be valid. You might think that providing reports in this way reduces your burden for supporting people with new reports, but in ...


13

In an ideal Agile world, you agree a price up front and a number of hours, but not scope. The customer decides what the minimum useful product is, rather than the product they really want, and that should estimate well short of the number of hours agreed. Then you deliver to them iteratively and they change their minds all they want, but you never go over ...


13

One thing I don't understand is, many apps have a Free version and a Full version. Some do, some don't. There's not one specific reason, like "the app store guidelines say you have to do it this way." There are several reasons, including but not limited to: Setting up and administering in-app purchase can be a bit complicated and an ongoing hassle, ...


12

Here it is how it goes in simple words. You put some money aside while working for a company You quit you daily job and start freelancing You transit form freelancing to business by either: a. Hiring other people that you will share your workload, which makes you a services shop. b. Come up with a cool idea and build a product that sells. c. Or Both. ...


12

I hope you don't get hit by a bus! You are correct, I don't see the value of doing this. First, the other company will charge an amount closer to a full time developer and they will critique things and slow you down. They may ask for too much deliverable and explanation from you. Also, there is no real guarantee that they will be able to pick up, since there ...


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