4 ms·

> All projects that I got into had nasty, unnecessary issues. Almost all of them were started in a rush, to get the business off the ground and had created a pa

> All projects that I got into had nasty, unnecessary issues. Almost all of them were started in a rush, to get the business off the ground and had created a parallel business of supporting the customers through all the defects they had. It’s almost like the businesses were caught in a startup limbo, for years. Sometimes decades! Working in such a company can take its toll on someone. So what is more important to have: (1) a product with bugs which can be sold and raises money, (2) a piece of software that has no bugs but also shipped x-times as late thus only learns you your true requirements x-times as late. For someone bashing on ivory tower architects in the subsequent lines this sounds like pure irony. The mythical software engineer that doesn't produce bugs. > Most defects in software come from poor engineering. In my experience most defects come from not knowing the exact way your software will be used by the customer. Sometimes because of not asking thoroughly but more often because the customer doesn't know yet exactly. Also in my experience most bugs are actually change requests in disguise. Actions that you didn't imagine and never designed your software for but are executed by the customer and now cause trouble to your software. > Oh and yes, design, architecture and other fancy words, are just engineering in the software industry, because it is not mature enough to have that level of abstraction, in which the architect draws the picture and the engineer implements it in such a way that it almost 100% of the time is right on the money. No. Far from it. What happens in reality is that the engineers try desperately to make the system work somehow, while maintaining the illusion of the story told by the architect. I feel sorry for your loss. You must have worked in awful environments to think about it this way. The next few sections I skimmed through read like the author is not proficient in software engineering at all which make me doubt if this is experience from some coding (scripting) side-projects rather than a full-time professional software engineer.

bob1029 5y ago
The trick between imperative/functional programming is that there is a balance involved. Some things make a lot of sense to put in a for loop and wrap with a try/catch. Interfacing with the real world is where I write the most of my dirty code. In software I am responsible for, the closer you get to the domain model, the more functional it becomes. In my mind, the entire point of imperative programming is to construct a sort of "matrix" in which the functional programming can exist without having to be aware of the uncertain nature of the outside world. If you want to build something complex really quickly, start with the domain model. And start with excel, not visual studio. Sit down with a spreadsheet in the conference room with all your business stakeholders. Iterate that document until every business person AND developer agree that it covers the needs on both sides (facts + normalization). Once you have that document completed, write the quickest & dirtiest MVP you can tolerate against it. Convene another meeting with the stakeholders. Check your gaps. Make another spreadsheet. Do this about 4-5 times, and then you can write "the one".

bob1029 5y ago

The trick between imperative/functional programming is that there is a balance involved. Some things make a lot of sense to put in a for loop and wrap with a try/catch. Interfacing with the real world is where I write the most of my dirty code. In software I am responsible for, the closer you get to the domain model, the more functional it becomes. In my mind, the entire point of imperative programming is to construct a sort of "matrix" in which the functional programming can exist without having to be aware of the uncertain nature of the outside world. If you want to build something complex really quickly, start with the domain model. And start with excel, not visual studio. Sit down with a spreadsheet in the conference room with all your business stakeholders. Iterate that document until every business person AND developer agree that it covers the needs on both sides (facts + normalization). Once you have that document completed, write the quickest & dirtiest MVP you can tolerate against it. Convene another meeting with the stakeholders. Check your gaps. Make another spreadsheet. Do this about 4-5 times, and then you can write "the one".