gashmol

Managers.

Pure Top down only works for small problems or problems you already know how to solve. Its main issue is that you don't know whether the solution is correct until you reach the bottom.

Structured Design, which is a quasi top down method, works better in real life. Its main issue is that it didn't survive the OOP hype.

A chrome extension for showing a preview (summary and screenshot) of a link on hover.

Android app for saving webpages for offline viewing.

Software Estimation: Demystifying the Black Art is a good book on the subject.

I think there are other ethical issues you should be worried about before this one.

It has one chapter that sumarizes refactorings. Enterprise patterns or design patterns in general are about software design. IMHO design patters are the worst way to learn about design in software.

I would skip Uncle Bob and Marting Fowler's books and just read Code Complete. It has everything you might want to know about coding and then some.

High Output Management - for general management issues.

Software Project Survival Guide - for software specific issues. (Don't be discourged by all the documents it discusses.)

Thanks, I'll check it up.

Which book would you suggest to read first?

As a form of testing I think there are two main reasons:

1. If we need to push this feature now, some say, reliability and future modifiability only get in the way. Under pressure people tend to focus on mere survival.

2. Developers don't know how to test properly. Namely, they don't know which tests to write and which not. That leads to excess of work, all while many errors (bugs) still find their way into the software. Naturaly, testing seems like a bad investment.

It reminds me of The Matrix.

The machines tried at first to make humans always happy in the virtual world they've created. They did that not out of care for humans, but in order that they could peacefully harvest energy from the oblivious humans' bodies.

As I remember it, it didn't go well in terms of production. So, the machines replicated the real not-always-so-happy world instead.

I'm not trying to suggest anything btw.

Or, am I?

> Most people, esp. in the US especially and in Western Europe in general fake happiness. esp in public. With true friends less.

I think it's largely true. Interstingly enough there are parts of the world where faking unhappiness is the norm.

> It is impossible to engineer long term true happiness. Or at least nobody has figured it out yet.

If happiness depends on externals than its indeed immpossible, since no one can control externals all of the time.

Stoicism was such an attempt to bring about happiness. By instructing its followers to dismiss any will for externals and focus on internals instead, it aimed to make them happy. It may have been seen like a bulletproof plan.

Unfortunately for stoics, though, you can't control internals either. Freewill is at best limited.

50% of the time talking sounds like a nightmare. I don't think you can build anything nontrivial if you get interrupted all the time.

High Output Management covers alot of it and then some.

It sounds that you lean heavily on OOP methods.

I find OOP to be weak in the design stage. It does help later to simplify the code. But, only after you find out where the actual objects are. I prefer ERD for any modeling I might need in the design.

Older methods like structured design and data-structured design offer better guidence in the design stage. Too bad people look down on anything that is not OOP (or the newer hype FP).

The most useful method by far, however, is to recognize the shape of the problem, look for and apply a known solution.

What kinds of sketches do you draw?

Try to write pseudocode for the critical parts so you can test your design before you write code.

I start with high level design to have a chance to get the required performance, scalability and other targets. Then, it depends on the particular problems I encounter. Sometimes I'll do another phase of design, other times I'll just code the solution since it's something I've already seen.

> I basically end up writing pretty much anything twice

That's how top down usually works. It's good for problems you've already solved before.

You can't have it all. You may achieve simplicity but it's not easy. Rails has most of what you need for a web app, and its ecosystem has many complementary subsystems and libraries. So, it's very easy to develop something fast. But, after a certain size it starts to be less and less maintainable.

Overworking the prototype is a real risk, that's why experienced devs should work on it. Sometimes its enough to do it on paper. Whats important is to capture the product in an objective form as quickly as possible and then show it to users.

Don't you think that iterating on a software MVP is more wasteful than iterating on a prototype? By the time you finish to setup the dev environment for your MVP you could've finished the prototype. And you don't have to carry any technical debt going forward.

I think there's should be a difference between customer feedback and user feedback. UI prototype is effective only in finding what users want. To get customer feedback you probably need a full fledged MVP and ask for money or other kind of commitment.

> but what if there were faster, cheaper and effective ways to get customer feedback than a UI prototype for a fresh startup just a few days old?

Like what?

IMHO its better to start with a UI prototype. It's much faster and cheaper while still being effective.

If you substitute writing with developing software (or prototyping) and ideas with requirements then you get great advice for making something users want. It even suggest the practice of checking requirements to be precise and complete. Intersting.

How about the time when Israel rescued some 14,000 people of this community in 36 hours from Addis Ababa just before rebel forces arrived at the city?

Israel made some great things for this community and it made some awful things as well.

My point is that if you get your information only from the news than you are bound to get a biased picture of reality.

You can always cherry pick news items to depict Israel as bad or as good as you want to. But remember, reality is more complex than what's on the news. While there are some terrible mistakes, Israel's treatment of Ethiopian Jews is definitely not terrible.

Generally speaking, you can reduce the combinatorics in tests by using techniques like cause effect graphing (from The Art of Software Testing). It also contains notation for cases that "can't happen". It's very technical so I'm not sure if it will solve your problem.

I think there is another big issue related to Clean Code (and friends) that is rarely discussed.

There are two types of design methods: those that help you to generate a solution to the problem and those that only help you to optimize a solution, in some dimension, once you have one. Clean Code guidelines clearly belong to the latter.

When you first write code you should not think of Clean Code. It will distract you from solving the problem at hand, while not providing any help in solving it. Only after you have a correct working solution you should consider Clean Code and other optimization guidelines. (Code Complete is much better IMO.)

Knowing when often pays better than knowing how.

Are you sweeping something under the rug? Loss of interest or pleasure is a symptom of depression. When you get rid of your depression, you'll enjoy programming again. If you don't think you have depression or other issues then try to find a challenge in programming. For me going through Programming Pearls got me hooked again on programming after a period of boring work.