It sounds like you just haven't participated in a well-run SCRUM process. You have to understand--SCRUM only makes room in the backlog for stories with points, and only points count.

You sound like someone that read a book "Lean these 10 steps that successful business people do and become wealthy rich". With a twist "Learn these 10 SCRUM steps and make any software a big success" Software does not work like this.

I have 30+ years of developer experience and I have seen every trial to quantize software development and the all fail to understand what makes software projects a big success: "Human nature that does not want to be contained into a quantized number " You end up with brainless code monkeys.

• Code monkeys: "No I can't do that, no I cant do that, no I can't do that, no it is not in the scope."

• Good developers: "Of course I can, give me a week and I come back when it is done."

• Code monkeys: "Cool we these predefined jobs set in stone for the next 2 weeks. If we fail we don't care"

• Good developers: "I am not allowed to do anything else for 2 weeks? I am outta here, bye"

• Code monkeys: "We encountered this bug but we can't fix it until 6 months from now. If you crash then just reboot"

• Good developers: "We found a bug that could cripple business, lets fix before it is released to because we love our hotline people and don't want them to get overworked"

I think scrum masters should ask their development team the following question: "If there was no economic crisis and you are not scared of losing your job, would you stay here with this scrum?"

By the time these companies start scrambling to use SCRUM they have already accumulated several years worth of technical debt.

That is exactly what is happening. SCRUM being used as some magical cure by people having a fast track in becoming a scrum master. Any deviation from the planning you did 2 weeks before and you get back stabbed. The flaw is the human element.

What I noticed that it is always like this:

• Sprint 1: Everybody free and enthusiastic and they race to get that deadline done.
• Sprint 2: Because they succeeded the deadline before they race try to do it a second time, but with less energy because they used it up in the first sprint.
• Sprint 3: Developers more tired of sprint 2 so the graph is showing slight failure but still OK.
• Sprint 4: Reduced planning because last time they overestimated the planning.
• Sprint 5: Yet again slipping of the planning, but the scrum master tells everyone it is OK we will plan even less next time.
• Sprint 6: Scrum laster had to promise business that this time they will succeed in the planning and promise back on track, so increased pressure on the team.
• Sprint 7: Team getting more and more exhausted, planning slipping again, business getting upset and the scrum master is afraid to tell business that the planning is failing again.
• Sprint 8: Stressed out scrum master, snapping to his developers team, team members snapping out to anyone that makes mistakes.
• Sprint 9: People looking out for other companies, and some of them out for weeks with sick leave.

I have seen this time over time over time again and again.

The failure is that there is never a relax moment where the team can do anything they want for lets say 2 weeks. Stuff that needs to be fixed before going on the next sprint.

What probably could work is Sprint 1, Sprint 2, then 1 month no Scrum to relax, to fix the stuff they could not do during a sprint. The sprint 3, sprint 4, again relax.

Good developers will have a tendency to cerate quality code. They will tend to want to succeed, and failure is always taken as "I have failed" at an subconscious level. You can keep on claiming that "you should not take the failure as personal", only psychopaths won't care. A continuous string of deadline misses will make good developers depressed over long term.

Over the years I have met numerous good developers that are years sick at home with depression and burn outs.

For me it is very simple: If I have a series of deadlines that I fail, then I feel bad and jump onto a next company when one becomes available. I have not chosen the developers profession to have the feeling that I always suck. I have chosen it because I can turn give solutions that are professional and are impossible to succeed to a complete success. It is the fact that day by day I have performed a small miracle that is the driving factor that makes be great to be a developer.

The issue is that both SCRUM and agile tries to mimic how I develop. The methods I use is very agile, and very reliable for very critical projects. I do have structures like daily builds and TDD like development.

However! My success is based on releasing when the time is right, never because of time is up. I will never commit a change that I do not trust. I will delay a commit up until the moment I have tested every part. I can also never predict what I am going to work on today. I optimize my development depending if I have a good day or not. When I have a razor sharp focus I go and get the toughest part, if I feel less optimized then I do the stuff that can't fail. But here is the clue, when I encounter a bug, I will hunt it down until I found I even if it takes days. The crazy thing is that I do all this in half the time a SCRUM sprint would take and zero stress.

Everybody knows about Raspberry Pi, but hidden in the dark regions of Internet there is another type of small motherboard called Parallella. It is more expensive that Raspberry Pi but has one very interesting feature that it has a second module with 16 core RISC processors (aka Epiphany) next to its main processors that can execute RISC code.

There was supposed to be a 64 CPU version but they halted selling this because they did not get enough money to mass produce it.

It is a talk for Paralella processor, but interesting to learn how parallel processing languages work.

He also talks about the "Transputer", some kind if parallel processing that would take over the world (1984). Failed because of lack of funding.

• Programming sucks because of SCRUM
• Programming sucks because the only person that understand what you have done is you.
• Programming sucks because the solution to a problem is ridiculous elegant and simple once you solved it.
• Programming sucks because the majority of programmers you encounter have knowledge based are partly science and partly superstition. Once the superstition is in your design then your project will fail.
• Programming sucks because if you have less bugs in your code, it gives the appearance that you did nothing.
• Programming sucks because the code that you created will be erased in a couple of months from now.

Prove you can build a framework or technology stack that is just as useful.

Definitely this! When you can build frameworks from scratch that are reusable and are actually functional, then you have proven yourself.

Consultants are in no way "credible". Their only credibility comes that they cost more and therefor must be better than you own low paid developers from managers point of view.

The main rules with managers:

• He talks hibrisch I don't understand: Therefore he must be good.
• He is 4 times more expensive than my current developers: Therefore he must be good.
• He is better dressed than my current developers: Therefore he must be good.
• He changed company every 3 months: Therefore he must be good.
• His project took 4 times as long with tens of thousand of bugs popping up and 3 of our developers ended up in a burn out. Luckily we had him in our team that saved the day.

Avoid companies that declare their process methodology, and run from anyplace that uses the keyword "scrum".

“I must not SCRUM. SCRUM is the mind-killer. SCRUM is the little-death that brings total obliteration. I will face my SCRUM. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the SCRUM has gone there will be nothing. Only I will remain.”

It took me 6 years until I became a senior developer and the decision maker.

I've been decades as a developer and when I give feedback then they ignore advice and continue down the worst possible road. Sometimes I wonder if they have actually understood what I said.

The flow in your logic is assuming that the only way to program is during company hours. The moment I learn the most is after my company hours because it is fun.

Services are harder to create, debug and maintain. Services also have another annoying thing, the startup sequence of the services cannot be predicted easily. Your service might start up before your SQL server.

In my experience with software developing, there is no single good solution.You have multiple solutions and the only way to know what was best is to try both of them. Even though it is a service or a Windows executable, you basic core code could be exactly the same. When 90% of your code van be used both on a executable and service then it can also be used in a unit test.

Also interesting to know, an executable can also be a service. When it starts as a service then don't use UI functionality but when you double click the executable then you do show the UI.

But using a programming language does not mean that you are a real programmer. Real programmers can design their own tools from scratch, most programmers use tools designed by real programmers, exactly like script writers would.

But that is the problem, the managers cared all about the perfect documentation, and did not care about the development. The development was for them a waste of time and took away hours from the project. I left that company of course.

I got the project that failed 4 times in a row before me that could blow up an industrial tank complex. Even though it got through functional application testing and service application testing I found 7 fundamental design flaws in it and fixed it. I had to fight to fix it. Since that company I refuse to deliver shady code.

Back in those days I had no idea that companies existed that were so bad. One single guy could blow up a complete industrial complex.

Just a warning, feed back does not mean that the user is right. It might be a vocal minority that wants something but the rest does not.

Edit: I just saw the part where you commented on a vocal minority. But my point is that sometimes users do not know what they want. They might say A but in reality they prefer B.

Theory and practice. Big difference.

Paperwork means nothing. I have worked in industrial software projects, the documents were perfect but the code was the worst I ever saw. It was written by kids that were taken from school because professional developers ran away from that company.

Second, some MCEs tend to think that they can increase the accuracy of estimation by adding precision and granularity — by breaking down large projects into as many small tasks as possible, maybe even hundreds of them, and asking for individual estimates of each small task. This is a catastrophically terrible idea. Increasing precision does not increase estimate accuracy. In fact it does the exact opposite.

This is exactly why SCRUM fails. You are trying to quantity something you have no clue how to solve yet. You can only give a predictable SCRIM estimation if you already created the project.

On paper SCRUM cloud work if humans were perfect and every developer was equal. In reality SCRUM is being used as some kind in mechanism to blame the developer that yet again he failed. They always blame it on either it was a bad SCRUM master or a bad development team. They never question if SCRUM actually works.They never question if SCRUM actually destroys your development team?

But the more precise and granular you get, the more likely you are to reduce your overestimates — which is disastrous for your overall accuracy. What’s more, the estimation of a hundred-plus features quickly leads to “estimation fatigue.”

This is what kills your development team in SCRUM:

• Sprint 1: You ask your team how long it will take and they will be wrong. When your team fails they feel bad.
• Sprint 2: So you ask them another estimation and this will also fail. Now your team feels double the failure.
• Sprint 3: New cycle again your developers team has to predict how long it will take, but they are scared now to give a number because they feel bad if they yet fail again.
• Sprint 4: Your team end up fighting each other because they are overstressed that they will fail again.
• Sprint 5: Managers gets nervousness because of these many failures they now force the developers team to be do even more their best to have correct estimates.
• Sprint 6: Your development teal self destructs and some of them probably have found another company.

I always get this excuse of SCRUM proponents that you should not take failure personally and that they blame no one, but good developers are passionate people and care about good end results. Good developers will always take failure personally. It kills good developers.

"It's better," the evangelist would say, "because with Waterfall you're determining requirements when you know the least about the project." It's absolute bunk.

Exactly.

Who are these idiots that think that there is "either Waterfall or SCRUM"?

It is not or or this, but it has a very wide range between agile and SCRUM. Nothing prevents you to combine those, long term goals and short term goals that are adaptive depending on what you encounter. Nothing prevents you to move the deadline ahead or back depending on the level of quality you have reached.

I also heard about it is either "Top Down" or "Bottom up"

That is foolish, you top depends on your bottom and your bottom depends on the top. You need adaptive coding that jumps to top and bottom depending on what you encounter. Adaptive coding also means that you have to go back to changes you did before you discovered that if you continue this way that you will end into trouble.

No one sits down and designs a system any more. They just cobble it together from little pieces they googled up from stack exchange.

Completely agree. Developers have lost the ability to think ahead and design structures. When you look at the code nowadays, it is just fragments hacked together.

And the other crazy thing is that every application must have a database. Developers have no clue that a lot of code can be created without the need of a database and the cloud. They are using the database as some giant Excel spread sheet to solve a problem.

• Customer: I have 10 values that must be sorted in alphabetical order
• Developer: I save everything to a database and return the values as: Select x from table y order by x

I blame a lot of this mentality on the thought that you can patch anything, anywhere, regardless of the innumerable problems it causes.

Exactly, ship beta products and if people complain then we give them a path.

1. More developers.

2. Slow down.

I disagree, Adding more developers add more problems. Slowing down means that come to a crawling halt.

What does work is, getting rid of subscription and SCRUM that forces people to deliver every single period. The best software was designed when it was only released when the quality reached a certain level. The quality needed to reach a certain level because it was distributed on CD and you can't reach the clients in time when you found a bug.

Welcome to the age of agile and SCRUM development and rapid release cycle. Daily builds and 2 week release cycle have become more important than the quality of the code. We know it is buggy but we will release it anyway and fix it next time

The last 5 years we have created a generation of developers that that have no clue any more that quality code means: Fastener development, better development, faster testing, and making the user happy.

These developer don't even realize any-more that the job that they do can be done in half the time. When you tell them that you can do it faster and better but they have to give up that SCRUM deadline, they look like they saw a ghost.

But damn it pays good.

Not in my country.

When companies give job offers to kids that are still in school it means that that company has a hard time to keep their very own people. These companies wasted so much good talent that ran from the company that the only way left is getting school kids that know no better.

When, I was in schools I saw many students get hired and stopped their education because why not, I already have work? Then one year later they get fired and there they are, no job no diploma.

Is that when you screw up in a scripting language you don't really find out until that code runs.

That is what I realized when I was learning it.

On how projects "scale", there are certainly python projects with hundreds of thousands of lines.

I checked the link but these are still small to what I am used to.

Interesting. In VS C# you rename the variable, then you get a tiny red sign, you click on it and everything is renamed.

If you want to get through HR selection, then learn the hype words and can name any design pattern in reverse order. You also become "average"

However if you want to become a great developer that will get a string of successes, then let go of these memorizing tools and learn to improve you instinct and especially "muscle memory" and work flow. Let go of these predefined libraries and tool sets, allow your creativity to flourish.

It is counter intuitive but forgetting in software development is also very important. The ability to rediscover a better way to solve something because you have forgotten how you did it last time. In software high intelligence actually works against you because you tend to become sloppy and never question your code if there are other ways that is even better.

Well it was not ethical to expose an AI girl to the dangers of the Internet.

First priority is get through HR selection. That is basically filling in a bingo list. Know as much bingo words as you can get. e.g. what does abc stands for in WCF services. HR have no clue what the job means or what they need. Their selection procedure never selects the ones that are the best but the ones that fits their excel spread sheet with bingo word.

The second problem is the boss you will work for. They won't hire someone that is smarter than them. If you are smarter than them then they don't understand you and paranoia dictates never to hire someone that cannot be controlled.

On Windows and C, there is only one winner: Microsoft Visual Studio (2010, 2013, 2015). I have all 3 running on my PC.

But what strikes me is the I want, I want I want, I don't want, I want, I don't want mentality. Wrong mindset for becoming a good developer.

I want to be able to set the color/theme so that 95% of my screen is black or very dark and doesn't burn out my cornea (My eyes are very sensitive after staring at the screen for 40 hrs a week)

Life as a developer means 24/7 staring at your screen. If your eyes already get tired that fast then maybe it is not for you.You must train your eyes to get used to it, because it will only get worse as you age.

No. Bootcamps are scams. You cannot get hired to do programming without a degree.

Yes you can. I don't have a computer degree only an electronics degree. I also see many accountancy students entering the SAP developersworld thorugh field vby

It is similar like a Windows service. In Windows a service is an application that has no user interaction, so no GUI, no message box.

Linux Chapter 18 - Daemons: https://www.youtube.com/watch?v=BL-NUeRmogo

So one success and one might be a success. So you worked on 2 projects so far?

The one platform that kept thousands of people paid, how many regression bugs were reported? How many fixes were not done because you are too scared to touch the code? How many change requests were bounced back because they were not in scope of the analysis from 2 years ago?

In programs using error codes, you have to go out of your way to handle errors.

What makes you think that you must use error codes?

public class BasicError  {
  public int ErrorCode {get; set}
  public string ErrorDestription {get:; set}
  public bool HasError{ 
    get {
       if (ErrorCode!=0) return true;
       return false;
   }
  public bool IsSuccess{ 
    get {
       return !HasError;
   }
}

Now how to use it.

public BasicError SomeMethod() {
  // Do something that fails
  return new BasicError() {ErrorCode=1, ErrorDescription = ""}
  else return new BasicError();
}

Here is how you use it

  var result =  SomeMethod()
  if (result.IsSuccess) result =  SomeMethod2()
  if (result.IsSuccess) result =  SomeMethod3()
  if (result.IsSuccess) result =  SomeMethod4()
  return result;

Now it gets more interesting

public BasicError OtherMethod() { 
  BasicError result;
   do  {
       BasicError CleanupResult;
       result =  SomeMethod()
       if (result.HasError) CleanupResult=Cleanup();
       if (CleanupResult.HasError) {
          result=CleanupResult;
          break;
      } 
  } while (result.HasError)
  return result;
  }

More variations

public BasicError  GetDateoverShakyConnction()
  var result =  OpenURL()
  if (result.HasError) result =  OpenBackupURL()
  if (result.IsSuccess) result =  DetectServiceType1()
  if (result.HasError) result =  DetectServiceType2()
  if (result.IsSuccess) result =  ExecuteWhateverYouNeed()
  return result;

And the grand FINALY!!!

public void Getdata() {
  var result= GetDateoverShakyConnection()
  if (result.HasError) Log.Error("We tried hard but failed with error: "+
                                            result.ErrorCode+" , result.Description: "+)
}

Clear and readable code, that can be easily extended, modified, recycled, reshaped...

I've worked on a number of large projects, both as a regular developer and as an architect and it's not that hard to make judicious, proper use of exceptions.

It is interesting that you left out if your projects were successful and actually useful.

I did not downvote you.

Triggering 100's of exceptions means that you can't use the debugger to find a critical bug in your software.

I mean if you have a code that throws an exception. And that code is inside a loop then you get 100s of exceptions in a row that stops the debugger even if you are not interested in that part. If you develop without exceptions then you can let the debugger run and the second the debugger pops up you know you have something.

The code that I develop, and never use exceptions, I can run it in stress tests millions of times in multiple threads. So I activate stop on exception and if there is a programming error in that part then the debugger will stop at the problematic part. Maybe hours later.

"overriding the return variable"? What does that mean? You can't override variables.

A technique that I use to create rock stable code during development.

 int valueBetween0And100 = Dosomething()
 DoSomething1(valueBetween0And100);
 DoSomething2(valueBetween0And100);
 DoSomething3(valueBetween0And100);

Overriding the variable:

 int valueBetween0And100 = Dosomething()
 valueBetween0And100=-1; // simulate an unexpected value
 DoSomething1(valueBetween0And100);
 DoSomething2(valueBetween0And100);
 DoSomething3(valueBetween0And100);

Now I move the overridden value to test other parts of my code

 int valueBetween0And100 = Dosomething()
 DoSomething1(valueBetween0And100);
 valueBetween0And100=-1; // simulate an unexpected value
 DoSomething2(valueBetween0And100);
 DoSomething3(valueBetween0And100);

And down

 int valueBetween0And100 = Dosomething()
 DoSomething1(valueBetween0And100);
 DoSomething2(valueBetween0And100);
 valueBetween0And100=-1; // simulate an unexpected value
 DoSomething3(valueBetween0And100);

So you tried using exceptions once 21 years ago and didn't like it.

Nope I encounter them all the time in failing projects.

You will not convince me you know anything at all about this topic.

I am not trying to convince you, I am telling how to make rock solid, stable, compact, fast performance, thread safe code, that scales incredibly well and has near zero bugs when you deploy it: Exceptions are not your friend.

Don't worry, you are not harsh. :-)

can't fathom what makes you think you get to comment on this with any authority

As I already have said here, when projects turns to hell, I am the on that gets called to fix it. On top of that I used them 21 years ago "Professionally" when they were new and shiny, but pretty soon discovered that they caused more problems than solve things.

Yes you can rewrap the original in a new type of exception and add them to the InnerException, but when you look at the code your catch becomes bigger than your try part. You are burring your functional code inside catch code.

Avoiding throwing exceptions forces you to create your code in layers. Layers that in the long run can be migrated to projects and refactoring way more easily than when you use exceptions. Also the code without exceptions are way more readable, more compact, more user friendly and way more easy to debug. You don't have to take my word for it.

This is fairly poor and naive advice as should be guessed from the absolutionist tone.

They all say that I am wrong, but in the end I am the one that is saving them when their projects fail. :-)

Not sure what kind of programming environment you live in, but thanks to the fact that I can fully inspect a caught exception, I can know exactly where the error is without even debugging (hint: logging + stack traces).

Only if you designed the code yourself and know every part of that code. But you will fail when you get back to that code 2 years later and have to fix issues.

The 2 epic sentences I always hear are :

• I don't understand my own code anymore that I created last year.
• No, we won't change that because it works and we don't want to break stuff. It is too hard to fix.

When you avoid using exceptions then you hear this:

• I have not seen this code for a year but yes we can change it with almost no risk.

One more tip.

If you are confronted with code that does use exceptions a lot realize that that catch statement can be way more simplified.

You can, create a method like this (I need to go to bed, so a draft version to get the idea)

private void ProcessException(Exception e){
    if (e is Exception1) {
         var ex1= e as Exception1;
         log.WriteLine(ex1.Message, ex1.SomeProperty1)
   } if (e is Exception2) {
         var ex2= e as Exception2;
         log.WriteLine(ex2.Message, ex2.SomeProperty2)
   } else  {
      log.WriteLine(e.Message)
}

Now you can use it like this:

public methiod1(){
  try {
   // do something
  } catch (exception e){
    ProcessException(e);
  }
}
public methiod2(){
  try {
   // do something
  } catch (exception e){
    ProcessException(e);
  }
}
public methiod3(){
  try {
   // do something
  } catch (exception e){
    ProcessException(e);
  }
}

It reduces the catch part because it is repetitive and exposes the real functional code from obscurity.

And you can even migrate the ProcessException() to a different class that extends intelligence to report the exception more easily

You are absolutely correct.

I recall that when Delphi 1 came out, or maybe even back in Borland Pascal 7????

I disassembled the code to see what it was doing. I recall that the "try" pushed the address of the "catch" onto the stack. When an exception happened then a jmp to that location was executed and it got into that "catch" code. The "Try" itself has almost no penalty, but the catch itself was a huge penalty in lost cpu cycles.

But in my experience it is not the CPU lost cycles that is the biggest issue, but these if your code gets big:

• Strange exceptions coming from out of the blue ending up in code that has nothing to do with the original exception.
• Your throw jumps to an unpredictable location that depends on runtime execution.
• Dumping meaningless stack traces for a user to see can makes them run screaming away.
• The stack traces cause by exceptions most of the time does not even give valid support for the IT support so they have to annoy the developer.
• Stack traces caused by exceptions most of the time are useless without trace loggings.

The idea of WINAPI GetLastError() returning just an integer is too cryptic.

The idea of an exception class that you inherit from is better, but the throw is what makes it bad. It is better to return the exception class as a function result instead of throwing it.

Abort() would be more like self destruct. LOL

Using excessive exception causes more problems than it solves. It only works on software that is small scale.

Of course if you never created big applications then would not know the difference. You would be convinced that the misery you get is normal and failing projects is part of normality.

The art of software :-) Many different solutions with many different outcomes.

But there is more in life than just factories ;-)

Also if the initial constructor takes 100ms to execute because it has some loading code and you move that 99.9 ms to the Init() then the execution penalty to call Init() is maybe a few microseconds.

You got it :-)

The rule should be that only throw an exception when your code have absolutely no clue how to deal with it. It would basically mean that in your code you have an "exceptional" situation and press the panic button.

But in production environments you will see tons of abuse by many developers because they are lazy and take the shortcut out. Small scale projects, it can work but as it scales in size in become one giant misery.

Wasn't one of the primary reasons to use exceptions to get away from error codes?

Actually no, it was an addition not a replacement. For simple components it works well but once you scale your projects it becomes a nightmare to debug. These projects becomes near impossible to refactor.

Also an error code return in a normal method does not mean that it must be a string or integer. It could be a complete class with tons of information about the error.

int error = MyFunction()
Log.WriteLine("Code: "+error.Code)

could be

ErrorCode errorResult = MyFunction()
Log.WriteLine("Description:"+errorResult.Description+ ", Code: "+errorResult.Code)
Log.WriteLine("Details:"+errorResult.ToString())

Extend it

do {
     ErrorCode errorResult = MyFunction()
     Log.WriteLine("Description:"+errorResult.Description+ ", Code: "+errorResult.Code)
     Log.WriteLine("Details:"+errorResult.ToString())
     if (!errorResult.IsSuccess) {
         RecoverSomething()
    }
while (errorResult.IsSuccess)

And now comes the interesting parts

do {
     ErrorCode errorResult = MyFunction()
     errorResult.Code = 100; // add this to test your code how it behaves when it has a simulated fail
     Log.WriteLine("Description:"+errorResult.Description+ ", Code: "+errorResult.Code)
     Log.WriteLine("Details:"+errorResult.ToString())
     if (!errorResult.IsSuccess) {
         RecoverSomething()
    }
while (errorResult.IsSuccess)

Remove the test error code by adding a comment in front of it

do {
     ErrorCode errorResult = MyFunction()
      // errorResult.Code = 100; // add this to test your code how it behaves when it has a simulated fail
     Log.WriteLine("Description:"+errorResult.Description+ ", Code: "+errorResult.Code)
     Log.WriteLine("Details:"+errorResult.ToString())
     if (!errorResult.IsSuccess) {
         RecoverSomething()
    }
while (errorResult.IsSuccess)

As you have noticed I can now building "readable" recovery loops that are easier to follow without obscuring the real functionality.

But the Init() can also be reused to recycle an object that was already created. That class might be only used in your factory but that code could maybe also reused outside the factory in future projects.

Now comes the interesting part, when you go to multi threading usage of that class. You can create the classes fast in one thread and then let the slower Init() execute in parallel threads.It simplifies your code to track what objects initialized successfully and which ones failed.

In small scale projects, of course Init() might be overkill, but my experience is that code gets recycled and ends up in bigger projects. And the fact that you see Init() in a class is a warning that this class could have a speed penalty when you use it.

When you design the class with Init() up front first, then later you can always optimize your code by commenting it out and see where the compiler stops. It is harder to find in your code all locations where the classes gets created and add the init().

Throwing an exception should be the last measure,

That was my intention to say.

It also depends on the situation:

• If your project depends on a critical WCF service that is not there then throw an exception.
• If your projects depends on a critical WCF service on a G4 network that is shaky as hell, then don't throw an exception but return a normal error code so you can create code to retry. If 10 retries fail then throw the exception.

Reformatted for clarity. (check out the <> button) to write code.

Don't

constructor(Member member) { 
     this.member; 
}
 public setMember(Member member){
     this.member = member 
}

Do

constructor(Member member) { 
   this.setMember(member); 
}
 public setMember(Member member){ 
   this.member = member 
}

This is so true.

Decades after OOP came out, I notice that humans are mostly unable to program in them. For me it is natural to do so, but for so many people they barely can grasp it.

Microsoft SQL server on your Linux server means a NSA back door and Microsoft targeted advertisement straight to the Linux users.

I see a pattern here. They are trying to take over Linux from within. That effort into the Linux community will come at a cost where Microsoft will charge subscription money to Linux users. Or worse try to sneak in a Microsoft Patent and then charge for it 2 years later.

the model works well in the Agile context due to the short sprints and multiple iterations.

I say it again, agile and SCRUM creates crappy code. You get the false sense of doing a good job while in reality you are crippling your development team to the worst developer.

If you want to have an cross OS app, at least skip the Windows version because no one uses the Windows Phone and tablet.

Focus in what the other OS really shines in.

I have not seen innovation, the only innovation I have see in increase in advertisement technology and spyware technology.

Actually when you look at applications, they start to suck more and more. Office used to be good but now it is basically a FB clone with integrated Skype, messenger and Bing.

On 9 February human error resulted in 11 deaths and 80 further casualties in tragic wreck near Bad Aibling, Germany. Despite a supposedly robust safety system, a lone operator was capable of affecting great tragedy.

The user cause the train wreck. It is tempting to blame the user while in reality the system sucks.

This blame-the-user is found in many enterprise applications. Instead of taking responsibility as a developer to improve the software that it prevents user to make mistakes, the developers tend to blame the user that he did not follow the procedure defined in the manual.

The italics were designed to tackle problems such the indistinguishability between a lower case “l,” an upper case “i,” and the number one.

If your code depends on this distinction then it is time to give your functions and variable better names instead of using this font.

It is confusing, so I uninstalled it now that the trial expires. When I buy software I prefer simplicity and not some kind of software that might or might not work when I need it the most.

Impressive reply, I have good starting points now.

I had my share of issues with this one before. You are overwriting "i" with 0 and depending of the compiler optimization this i could be the i next to the int array[10] in memory or some other local variable.

int array[10],i;
for (i = 0; i <=10 ; i++)
    array[i]=0;

Should be

int array[10],i;
for (i = 0; i< 10 ; i++)
    array[i]=0;

When you have mysterious error in C++ code that makes no sens then reverse the local variables:

int array[10],i;

to

int i, array[10];

or add a dummy

int int dummy[10], array[10], i;

Also realize that 2 different functions in 2 different source files could be finally compiled very close to each other in memory interfering with each other.

How do I avoid traps like this? By building a code base that I can rely on. When mysterious bugs occur then it is easier to track in what you changed before.

These have a preferred directory structure and all examples assume you use it: "src" for the sources, "doc" for docs, "include" for public (!) includes. Binaries will be built into a subdir ".libs" or into an architecture-dependent directory - but that's automatically handled by automake anyway.

That is important to know. Thanks

That is exactly what I need. :-)

I think for Linux, it should be C++.

But I am more interested in the folder structure of c++ projects. I can create a hello world program, but how would a "professional" Linux application project in source folder structure look like, that scales well? The folder structure is completely different than a Windows structure.

Jesus the marketing BS is dripping from this blog. This should never be under /v/programming.

Maybe people have not noticed but smartphones and tablets now gets filled with hundreds of apps. And they are all screaming for attention and all want to get your private data and snoop into your calender, browser history and emails. Apps are becoming the new advertisement wit badly written apps that wants your attention.

Now what do people do when you flood them with stuff? They get fed up and uninstall them.

The hard reality is that smart phones and tablets gets so many apps installed that these devices becomes useless. Especially then numerous updates you get almost daily. and every update that stupid app yet again wants your login and password. Not only that but many of them are eating up your bandwidth and battery power.

The interesting thing is what is going to become soon. Aging tablets, smart phones that can't run the latest apps. The OS does not support it, your memory is too short,... Are people going to buy yet again a new smart phone/tablet? or will the revert to the old ways because it is too costly to continuously upgrade the hardware.

Our mobile app developers are avid mobile users and understand the way modern mobile web operates.

This is called marketing BS.

If you see this on a web page then you start to wonder whet else is marketing BS.

Also what makes an app great is because it is designed for that device. It is optimized for that device. If you use tools like this then you app becomes average, lower in ranking and probably never gets off the ground.

The thing is 20+ years in development means that you are the fittest of the developers to bring a project to a success. If you weren't then you would have changed job long ago.

When you have 20+ years of experience in coding then you don't care about the syntax anymore, you understand complete projects. One of the thing developers always forget is to add your code in such a way that it can be easily tested by testers.

You are right about this. I never use the word "coding", but "programming" in C#.

And scripting I use in small hacks, like compile scripts, or stuff to move files. These scripts are intended for other people to be modified easily that are not that deep into programming.

You could say:

• Coding, when the end result does not contain the original source code.
• Scripting, when the end result requires the source code.

Coding languages tends to have very scalable projects, with scripting you pretty soon reach the limitations of that language pretty fast.

I do not know about Java but I think it is the same as C#.

C# is compiled into IL (some kind of virtual assembly). The original source code does not exist in this IL. This IL is then converted to processor specific machine code on the go.

The distributed assemblies do not contain the original source code anymore, but in the case of scripting it has to contain the original sources.

I have to admit that you are right the correction I made was a mistake. 19 was the number of characters in my corrected version, but in this case it prints until it encounters the "$", so 9 was the correct number.