I didn't understand the responsive design analogy. I assume it's not the operating system that the developer responds to, so what is it?
How I Develop Things and Why
21–30 of 35 posts
Re: How I Develop Things and Why
#22Earlier quoted context omitted.
This is very important, but he's making a deeper point, that the README ties it to the problem it solves. It's possible to make a beautiful, intuitive, natural solution that nobody needs (not even yourself). From the user to the code, it goes: problem -> usability -> code Although intriguingly, pure mathematicians create solutions for their own sake (without reference to a problem), and it sometimes (often?) turns ou…
Pure mathematicians are always motivated by a problem, even if it isn't a "real world" problem.
So might they too fall prey to the same issue, of losing sight of the problem they are solving?
i.e. that the equivalent of a README would also help pure mathematicians? I guess that would be a statement of the problem: a formal definition of assumptions, and the outcome (if possible). Though I think getting to that point would be where most of the work is.
Re: How I Develop Things and Why
#23Earlier quoted context omitted.
I write the tests first which is kind of the same thing except that I can actually execute that API and see if what I wrote actually works. Writing good tests first also helps me constrain my implementations to be as simple as possible as well. Otherwise my tests get hard to write and that's a sign things are probably going in the wrong direction. Often though you can't have your cake and eat it too. There are two sc…
No, written tests first means you make the code easy to test. That may make it easy to use to, but it is not likely. Easily testable tends to mean that the class knows to little. And as a user that you have to tell it too much.
> Easily testable tends to mean that the class knows to little.
No it doesn't. You've got a pretty big job proving that ALL TDD does that.
Have you ever read python doctests? They are a perfect example of tests that describe both functionality and usage.
Re: How I Develop Things and Why
#24Earlier quoted context omitted.
I write the tests first which is kind of the same thing except that I can actually execute that API and see if what I wrote actually works. Writing good tests first also helps me constrain my implementations to be as simple as possible as well. Otherwise my tests get hard to write and that's a sign things are probably going in the wrong direction. Often though you can't have your cake and eat it too. There are two sc…
The problem is that the worse is better school usually wins over the long run. Jamie Zawinski has a great essay on this [1]. Unix was a "worse is better" MULTICS. DOS was a "worse is better" CP/M. Windows was a "worse is better" MacOS. The advantage of simple implementations is that you can get them in front of users right now , and then iterate your implementation until you have something that's cheap and adequate.…
> Windows was a "worse is better" MacOS
Bad example, MacOS was out years before windows. Microsoft just got a massive market hack. It had nothing to do with solving a problem directly and then iterating...
Re: How I Develop Things and Why
#25Earlier quoted context omitted.
The problem is that the worse is better school usually wins over the long run. Jamie Zawinski has a great essay on this [1]. Unix was a "worse is better" MULTICS. DOS was a "worse is better" CP/M. Windows was a "worse is better" MacOS. The advantage of simple implementations is that you can get them in front of users right now , and then iterate your implementation until you have something that's cheap and adequate.…
> Windows was a "worse is better" MacOS Bad example, MacOS was out years before windows. Microsoft just got a massive market hack. It had nothing to do with solving a problem directly and then iterating...
MacOS (not that it was then branded as such) - 1984. Windows 1.0 - 1985. So not quite years really.
Re: How I Develop Things and Why
#26Earlier quoted context omitted.
> Windows was a "worse is better" MacOS Bad example, MacOS was out years before windows. Microsoft just got a massive market hack. It had nothing to do with solving a problem directly and then iterating...
MacOS (not that it was then branded as such) - 1984. Windows 1.0 - 1985. So not quite years really.
january 1984 vs november 1985... you going to get pissy about 3 months?
My point is still valid.
Re: How I Develop Things and Why
#27Sell first. Build later.
Re: How I Develop Things and Why
#28Earlier quoted context omitted.
No, written tests first means you make the code easy to test. That may make it easy to use to, but it is not likely. Easily testable tends to mean that the class knows to little. And as a user that you have to tell it too much.
> Easily testable tends to mean that the class knows to little. No it doesn't. You've got a pretty big job proving that ALL TDD does that. Have you ever read python doctests? They are a perfect example of tests that describe both functionality and usage.
I said tends to mean. That does not mean that it is true all the time, but that, a priori, it is the most likely outcome.
Re: How I Develop Things and Why
#29Sell first. Build later.
^^^^^^^ This. It is so important to be a great idea salesperson. Even if you are writing a OSS tool, if you want contributors you need to sell the idea.
Re: How I Develop Things and Why
#30Earlier quoted context omitted.
> Windows was a "worse is better" MacOS Bad example, MacOS was out years before windows. Microsoft just got a massive market hack. It had nothing to do with solving a problem directly and then iterating...
MacOS (not that it was then branded as such) - 1984. Windows 1.0 - 1985. So not quite years really.
Windows 1.0 was just a fancy dosshell. Windows 3.0 should count as 1.0 in this case I think :)