4 ms·

Not really. It would probably be better for the health of the company to direct all dev efforts towards marketing the current software (at a sane pace). For

by fleitz 16y ago

Not really. It would probably be better for the health of the company to direct all dev efforts towards marketing the current software (at a sane pace). For example: setting up mailing lists ad words ads on craigslist SEO A/B testing heck, even getting the devs to pick up the phone and do some old fashion cold calling. The closer devs are to the customer the more they will know about what customers want. Working 11 hours is counter productive, as a coder you should focus on mental state. It's far better to be highly productive for 3-4 hours a day than unproductive for 11 hours. Being unproductive for 11 hours just leads to working 12 hours the next day as you fix the bugs you put in yesterday. All you're adding to the code base at that rate is bugs. Being tired and in a poor mental state will lead to having two eyes on the goal instead of two eyes on the path. Time in seat does not equal working (or profitable) code. How does working longer lead to more profit? How does working longer lead to working code? Have customers asked for those new features? Are the customers paying for the dev effort? Software is a business with zero cost of reproduction, therefore its essential that a customer base is established on the minimal amount of code. One should not start writing code until there are enough customers to pay for the feature or a customer is willing to front the costs for the dev effort. It's not the dev's fault that management chose a set of features that is unprofitable. Rather than adding more unprofitable features you should focus on adding profitable features. Or focus on selling the features you have until it's profitable. If you can't sell the feature don't code it. Find out first by trying to sell it. Spolsky says one thing about features, DHH says another, the important thing is not who says something but how relevant it is to the situation at hand. As a user of Fogbugz I can tell you that one of the things I really liked about it was it's simplicity. Fogbugz for me was way better than JIRA which has many more features.

InclinedPlane 16y ago
Good tools combine powerful underlying systems with abstractions that bring the necessary complexity of the system into a realm that is manageable by users. When done well it can make a tool that took a tremendous amount of effort and which encompasses a great deal of complexity look effortless and simple. And more importantly be intuitive to use. If you look at a tool like a hammer both Spolsky and DHH would likely say that it was a simple tool. But that simplicity underlies a lot of complexity. The simplest hammer, the sort that a parody of DHH's ideals would lead you to believe he would advocate building, would be a simple suitably sized and shaped rock. Modern hammers are built using centuries of experience and a great deal of research. A great deal of metallurgy has gone into refining the exact variety of materials used in the hammer head as well as in the manufacture of it (drop forging). And not just in ensuring it is of a certain quality, but in ensuring that it is precisely suitable for its intended tasks. A great deal of research and experience has gone into shaping the head and the handle, and in their construction. Ergonomics, durability, efficiency, cost, etc, all of these factors are carefully balanced in the end product. When you hold a hammer you don't need a manual, it's operation is obvious and intuitive. The best tools work that way. It takes a lot of effort to learn how to drive an automobile properly because it is a complex task, yet the fundamental interface is nevertheless (today) very straightforward and intuitive. Take a moment to think about all of the various tools you use routinely, from silverware and pocket knives to automobiles and cameras. Are these tools simple or merely deceptively simple? How do these tools take control of the inevitable complexity underlying their operation? How do they bridge the complexity gap between the "user interface" abstraction and their fundamental operation? What characterizes better tools of each sort from lesser tools? The same applies to software as well. The language we use in describing software and its use is today incredibly crude and barely suitable for the task, which leads to many debates where neither side is capable of fully articulating their meaning and people are left with half-ideas of what either is trying to get at. I don't think Spolsky or DHH are necessarily arguing in opposite directions, I think they are trying to articulate the complex nature of something that is difficult to convey. Elegance is perhaps one aspect of it, but there is no single word that fully describes the concept that either is trying to get across, I think. Edit: Another perfect example: I occasionally use an infrared thermometer in the kichen. It is supremely intuitive to use. It is vaguely gun shaped, fitting easily in the hand. It has a single button, a trigger, and an lcd screen that displays temperatue and units. Pressing the trigger once generates an instantaneous reading which is displayed on the screen for several seconds. Holding down the trigger generates a continuous reading, updating the display perhaps a few times every second or so. Releasing the trigger leaves the last reading displayed as above. When taking a reading a red laser marks the targetted spot. The battery compartment can be opened without tools but is designed such that the act of using it will prevent the compartment from being opened. When you consider the complexity of such a device, how many various pieces have to be put to use (such as optics, sensors, processors and software to analyze the IR spectrum within a narrow beam and determine a temperature to high accuracy, not to mention all the supporting components like the laser pointer, display, body, power system etc.) it gives a greater appreciation for the incredible elegance of the tool.

by fleitz 16y ago

InclinedPlane 16y ago

Good tools combine powerful underlying systems with abstractions that bring the necessary complexity of the system into a realm that is manageable by users. When done well it can make a tool that took a tremendous amount of effort and which encompasses a great deal of complexity look effortless and simple. And more importantly be intuitive to use. If you look at a tool like a hammer both Spolsky and DHH would likely say that it was a simple tool. But that simplicity underlies a lot of complexity. The simplest hammer, the sort that a parody of DHH's ideals would lead you to believe he would advocate building, would be a simple suitably sized and shaped rock. Modern hammers are built using centuries of experience and a great deal of research. A great deal of metallurgy has gone into refining the exact variety of materials used in the hammer head as well as in the manufacture of it (drop forging). And not just in ensuring it is of a certain quality, but in ensuring that it is precisely suitable for its intended tasks. A great deal of research and experience has gone into shaping the head and the handle, and in their construction. Ergonomics, durability, efficiency, cost, etc, all of these factors are carefully balanced in the end product. When you hold a hammer you don't need a manual, it's operation is obvious and intuitive. The best tools work that way. It takes a lot of effort to learn how to drive an automobile properly because it is a complex task, yet the fundamental interface is nevertheless (today) very straightforward and intuitive. Take a moment to think about all of the various tools you use routinely, from silverware and pocket knives to automobiles and cameras. Are these tools simple or merely deceptively simple? How do these tools take control of the inevitable complexity underlying their operation? How do they bridge the complexity gap between the "user interface" abstraction and their fundamental operation? What characterizes better tools of each sort from lesser tools? The same applies to software as well. The language we use in describing software and its use is today incredibly crude and barely suitable for the task, which leads to many debates where neither side is capable of fully articulating their meaning and people are left with half-ideas of what either is trying to get at. I don't think Spolsky or DHH are necessarily arguing in opposite directions, I think they are trying to articulate the complex nature of something that is difficult to convey. Elegance is perhaps one aspect of it, but there is no single word that fully describes the concept that either is trying to get across, I think. Edit: Another perfect example: I occasionally use an infrared thermometer in the kichen. It is supremely intuitive to use. It is vaguely gun shaped, fitting easily in the hand. It has a single button, a trigger, and an lcd screen that displays temperatue and units. Pressing the trigger once generates an instantaneous reading which is displayed on the screen for several seconds. Holding down the trigger generates a continuous reading, updating the display perhaps a few times every second or so. Releasing the trigger leaves the last reading displayed as above. When taking a reading a red laser marks the targetted spot. The battery compartment can be opened without tools but is designed such that the act of using it will prevent the compartment from being opened. When you consider the complexity of such a device, how many various pieces have to be put to use (such as optics, sensors, processors and software to analyze the IR spectrum within a narrow beam and determine a temperature to high accuracy, not to mention all the supporting components like the laser pointer, display, body, power system etc.) it gives a greater appreciation for the incredible elegance of the tool.