479

You don't explain; not further, not at all. You just say no. This is your business, and your choices about how to conduct it are not up for discussion. The terms of any contract are up for discussion; before signing, that is. He's giving you multiple big red flags that this contract will be a miserable experience, that it will continue to be so even ...


449

The answer is surprisingly simple: those 'other industries' do have a high failure rate. We're just comparing the wrong things. Writing software is often called 'build', and so we compare it to the manufacturing or construction phases in other industries. But if you look at it, it's not construction at all: it's design. Software designs are written in ...


392

(Or, the flip-side of my previous advice...) You stop giving protestations, and say yes. "Yes, I would be happy to write a new contract for these additional deliverables. Project-complete tutelege in my proprietary tradecraft is valued at (value of my projected income for the next $N years). There will also be a licensing fee $Y, for physical file ...


337

Ed Yourdon's Death March touches upon a number of these meta type questions. In general, the software industry lacks a lot of the following, which gets in the way of large projects. Standardization and work item breakdown. This has certainly gotten better, but the design constructs still aren't there to break out a big system. In some ways, software can'...


180

To point out some figures: Change of requirements after implementation started; for example when the first Airbus A380 started to be created in the factory I cannot believe that if someone wanted 200 more seats, those would be put there; but in a large software project even after the programmers started development 5 more types of users can be added. ...


140

The premise of the question is a bit flawed. Both the A380 and the Boeing 787 were delivered years late. In the case of the A380 much of the delay was caused by the French and German units of Airbus using different and slightly incompatible versions of CATIA design software. This incompatibly manifested itself as wiring harnesses that didn't quite fit the ...


112

Skyscraper guy here. Not sure if I can answer your question but I can surely shed some light into various items in the thread. Buildings do indeed occur very fast. A major constraint is locale (regulations). But in general it takes 3 to 10 years for a tall building from start to finish. I think comparing a new building with a new software project is not ...


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 ...


80

I wouldn't deal with this guy, period. It sounds like simply doesn't understand that much of the job is thought. If you supplied him with the video he's going to nitpick all the time you spend ignoring him (thinking about the situation.)


66

From a business perspective, a bug fix is no different than a feature request. It has a certain cost in development time, and it has a certain value for customers. If a bug is non-critical, it can totally make good business sense to prioritize a valuable feature above the bugfix. But from a technical perspective, bugs may be more critical, because they ...


61

To be honest I use newsfeed reader. I subscribe to a number of blogs and technology related sites. I'll read my feed during lunch, before work and sometimes after work. However I use my tablet for that and will constantly review news sources for if they provide a good time to value ratio. I probably get 1-2 hours a day reading about new things. ...


58

I think the biggest problem (other than having an insane customer) is that the arguments you make are weak: Hundreds of hours of work on a dual-screen PC will require a large amount of disk space for the recorded videos. If I don't care about space, I do care about this customer wasting my bandwidth downloading those videos. Disk space and ...


52

The client doesn't understand software development if he thinks he needs a video of your work. A good programmer will generate the most value for the customer when they don't appear to be doing anything with the computer at all. Maybe he'd like you to start billing extra for those times when you invariably think of a solution to a problem during your ...


48

If all you have is 2 days and no time to prototype or even read upon all the alternatives then there's really only 2 options: ask someone who knows and follow their advice. This may not necessarily mean asking an individual but spend the 2 days searching through blogs and articles to glean enough information to make a slightly-better-than-uninformed ...


45

Biggest thing: DON'T. GET. FRUSTRATED. Hang in there. Do your best. Learn what you can. Steal every minute. Enjoy the process! Second biggest thing: Think long-term. Think, "In a year from now, I want to have XYZ accomplished." When I look at what I've done over the past 6 months, I'm really impressed. But when I think about what I've gotten done tonight .....


44

Then how long did the design of those took? Year? Two? Ten years? The design is the most complex part of building something, the construction itself is easy. Based on this article, it is slowly being understood, that software development is mostly design process where design document is the source code itself. And the design process is totally different ...


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 ...


39

Imagine, in the middle of the design of the Airbus A380, someone piped up in a meeting and said, "Heh, could build it as a triplane?" Others joined in saying, "Yeah, yeah. A triplane. More wings are better." The next thee years is spent turning the A380 design into a triplane. At another meeting, someone says, "A triplane? That's old. We want a biplane. Just ...


36

You should log every change you make to your system. There's nothing wrong with logging it after the event - as long as you link the bug report to the change number. Then if anything ever goes wrong you can track back to the bug and find out why you made the change you did. In the vast majority of cases you are right and no one will look at these ever ...


31

Really? This isn't one of the answers yet? Suggest to the boss that you've heard about newThing and that it could help the company, especially with hideousProblemWeJustHad. That's how I made my foray into unit testing. That's not super-cutting edge, but my school did a horrible job of teaching what it was all about and it was new to me. Part of the time of ...


28

Do it but require that the customer put your entire fee into an escrow account; otherwise, how will you know he will pay you? The escrow account should be created by a lawyer who will video tape all billable time spent on the contract. The client must record all time spent approving the software. Preferably one video file per requirement. If you're going ...


25

Get a new job. 10-11 hours in a job that's not fulfilling is crazy, and there is no way you could possibly fit any other activity in there, not if you have a family. Either find a job that's more fulfilling (there's nothing wrong with C++ by the way); or find one where you don't work crazy hours all the time; or talk to your boss to downshift to a more ...


22

Yeah - absolutely not. My first instinct is to walk away - at such an early stage of the process, if he's treating you like a thief - and that is what he's suggesting - then it's just going to get worse later when XYZ feature doesn't work exactly the way he envisioned. Not doesn't work to spec, doesn't work to what he thought the spec should be. If you ...


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

"How to explain to him that it is not an usual practice for the freelancers to record the videos of their daily work, and that such extravagant requests must be reserved to exceptional circumstances"⁴ Ask your customer: if you were an employee and not a contractor, would he stand over your shoulder and watch your work all day, every day? The answer is ...


21

As someone with a mechanical engineering background working in IT, I've often wondered about the reasons of the low success rate in IT. As others in this thread, I've also often attributed the failures to the immaturity of IT, the lack of detailed standards (yes I'm serious, have you ever checked the standard sheet of a simple bolt?) and the lack of ...


20

Why would you bother accepting a contract with such a pesky customer? If they don't trust you before you've committed to the deal it's not going to get better. It's quite possible your customer has been burned in the past, and that's something you can sympathize with, but you need them to understand that programming is intellectual work, and time at ...


19

First of all, the actual requirements should drive the decision behind what language, frameworks and tools to use. If the requirements allow you to work on similar languages, frameworks and tools, then you should definitely try to keep things as consistent as possible. You want to keep things similar for the following reasons: Less context switching ...


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.


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