Most feature requests arrive from a user telling you how they think you should solve some other problem. If you can figure out the real problem and solve it better, that will be an improvement over delivering the exact request as given. (If you can't solve the real problem, though, or you misunderstand it, that's worse.)
For example at one company I was asked to speed up a report. The problem was that it was running too slowly and was timing out in the browser. Instead of tackling that fun optimization challenge, I built a feature that would cause any report that took more than a minute to run to be emailed to the current user. My manager said that he received more thank yous for that feature than for everything else the team had done in the previous 6 months.
At another company I received a request to add a feature that would prioritize pushing specific pieces of data to the website. (We'd had some stability problems, and they had no visibility into what was happening.) I knew that adding this prioritization feature would further destabilize the data transfer logic that I was trying to make more robust, talked to my manager, and refused the request. The senior executive requesting the feature tried to get another co-worker to do it instead, that one asked me innocently how to go about it, I got him to push back. Several months later I got enough of a break from other projects to consider the prioritization feature and asked the executive whether he still needed it. His response? "It has been months since data took more than 5 minutes to get to the website, I'm fine."
Also it can help to generalize your solution. At a third company I built a reporting system where instead of just plugging inputs, every form field could template the SQL that was being used. So a report could also generate drilldowns of itself, and you could combine these in a very flexible way. After a while over 2/3 of the special report requests that I got could be immediately resolved by showing that it was available if you combined two features that had been added for other users doing something else. (My turnaround time for other requests tended to be under 2 hours - and the features, documented, were available for anyone who needed them.)
Programmers do not provide value by writing code. We provide value by solving problems more quickly and cheaply than the alternative. The better you solve problems, the more value you provide.
That’s why it was left to wizards, who knew how to handle it safely. Not doing any magic at all was the chief task of wizards—not “not doing magic” because they couldn’t do magic, but not doing magic when they could do and didn’t. Any ignorant fool can fail to turn someone else into a frog. You have to be clever to refrain from doing it when you knew how easy it was. There were places in the world commemorating those times when wizards hadn’t been quite as clever as that, and on many of them the grass would never grow again.
Along those lines... I was once asked to essentially "speed up a report" but after asking a few questions discovered that the user of the report actually needed only about two values out of dozens of pages of detail and summarized totals on the report. Everything else on the report had been thrown on in the initial design as "someone might need that" requirements.
We created a new report that delivered what the user actually needed, and it ran in a fraction of the time. The speed difference was so great the users in fact doubted that the report could be correct, until they verified it against the old one.
And that's something that frequently ends up being overlooked in discussions like this. Software development isn't special because you need to state it in terms of goals. Yet you don't see people telling surgeons "you should avoid operating on people" or architects "you should avoid putting unnecessary stuff in and on your buildings".
What makes software development special is the perceived comparative ease of doing the work: you just sit down and code. There's no risk someone's blood will get septic just because you sat down to code. One of the consequences of this is that eager, novice coders will churn out code they could avoid, because it's cool.
Cautioning coders to avoid unnecessary coding is good, as long as you don't start forgetting that there's necessary coding, too and that writing that code does, indeed, add value.
There is a lot of effort expended to find non-surgical alternatives to many health conditions. Insurance companies in effect tell surgeons "you should avoid operating on people for this condition unless these other approaches have been tried first" in their reimbursement guidelines.
And the architect Mies van Der Rohe is famous for his precept that "less is more."
There is a lot of effort expended to find non-surgical alternatives to many health conditions. Insurance companies in effect tell surgeons "you should avoid operating on people for this condition unless these other approaches have been tried first" in their reimbursement guidelines.
As for insurance companies, they have some interesting perverse incentives going forward. Obama's health care plan says that they have to spend most of the money they bring in on medical care. This is intended to keep them from causing too much overhead. However the flip side is that the potential profit the company and top executives make is directly tied to how much medical care they get people to have, with the costs passed on to companies and consumers who are now legally required to buy insurance.
They will be very interested in making sure that the cost of medical care grows at a known rate. The growth being so that they can make more money. The known rate being so that they actually can make money. They will give public lip service to cost saving measures. But privately that isn't their incentive, and they are smart enough to know it.
It's amusing how quickly programmers-turned-managers forget their roots. Look here:
I used to get a huge feeling of satisfaction from a weekend
spent working on a clever hack. I would spend serious
effort making something run twice as quickly, even when
there wasn't a problem with how quickly it was running in
the first place. Meeting those types of challenges was my
primary motivator.
This is how you were motivated before they gave you a manager hat. This is how the people you manage think. And I wager that this mindset isn't wrong by any stretch of the imagination - as a programmer, I love working around people who program for the sake of programming, who find fun and satisfaction in writing code.
I don't mean to suggest the perception of code as just one of many means to an end is wrong either; it actually makes perfect business sense. It's something managers need to understand. But in your "enlightenment" you've forgotten what made you tick in the first place - how do you translate your new business-value-driven mindset to something the people under you (who don't have that mindset) can appreciate? Hint: it's not by telling them their cool hacks are useless. And we wonder why programmers distrust management.
Actually, let me put this another way... back in the original dotcom era, I worked at a startup that decided to write a BIOS. With the amount of hardware we'd be selling, it'd save a million dollars! Well worth six man-months or so of work, right? WRONG. That was six man-months of critical programmer time when the time and money was running out, and all we learned was that we couldn't do it in a 512k PROM (not with our design anyway), and upgrading to a 1mb PROM would have cost more than a license from Phoenix for their BIOS.
That's what happens when you let the inmates run the asylum.
Programmers are fools, for the most part. They don't understand what problem they're really trying to solve. We thought we were solving a cost-of-production problem for a fully scaled business. That wasn't the problem. The PROBLEM was NOT DYING. And that meant getting a working product out the door as quickly as possible, even if it cost more.
Programmers are fools, for the most part. They don't understand what problem they're really trying to solve.
That's a little harsh. I think it's fairer to say that they often don't have insight into the wider strategic objectives of the company, and that's as much a company failing as anything. I'm now a firm believer in sharing e.g. revenue numbers with everyone in the company and explaining why they're important - people are much more willing to accept things when they understand the wider picture.
It's not just managers vs. coders. It's also experienced coders vs. novices.
You get tired of writing a pile of code that solves the problem the wrong way, so after 10 or so iterations of un-appreciated or un-used code, you learn to try to look at the big picture instead of always trying to isolate the problem into a fun programming exercise.
There is a management lesson here in being sure the right people are working on the right stuff. If you may need process improvement to generate the nightly reports by the next morning, don't send someone who loves to re-implement scripts in C. Or, if you're the person who loves to re-implement scripts in C, realize that your prospects may be limited.
> Hint: it's not by telling them their cool hacks are useless.
No, of course not. It's by showing/encouraging more ways to hack a solution. Writing code is one of many tools that can be used, and as the adage goes: "if the only tool you have is a hammer, everything looks like a nail." You can't pick the best tool for the job if you only want to use one tool.
I've come to a similar conclusion but I tend to think of it as solving little problems with the simplest solution possible. Don't pre optimize and don't pre abstract.
This is a thought process I think you arrive at when you're running your own business or in some sort of managerial role. You start realizing the constraints (time, budget, resources, etc) involved in building software.
When we first come into the world of software we just want to write awesome code. But to truly evolve as a developer you need to start asking real questions regarding what you are building.
Are we making the budget bleed by spending 3 weeks on making the most beautiful piece of code possible for a feature when it was originally estimated to take two days? Can an open source library be used instead of us trying to build something from the ground up? How does this feature add real value to the users of this product?
I enjoyed this but on the surface reading didn't like his "it makes me think an octave higher" line, and on reading the context from Sivers (an excellent article that, btw) I even more didn't like it. The analogy just didn't seem appropriate.
However, after some thought I felt the paragraph after with the bulletpoints does actually line up quite nicely (albeit rather obliquely) with what Sivers was talking about and I think I get it now, the finer points just weren't immediately obvious. This a minor niggle but I think that he could have explained that part better, and without requiring a whole other article for context (no matter how good that article is!).
Sometimes you have to write software to make all the other option much more efficient. Let give an example, we at MobileWorks (https://premier.mobileworks.com) are in business of providing virtual temps to businesses. Since we are built to scale, the entire team has virtually unlimited supply of temporary labor and we use it A LOT.
However, in a lot of cases a little bit of code actually makes the temps much more efficient. That's the real value of code. Making the mundane much more efficient.
I think this is more about "feature creep" than specifically about code, though the OP's point is well taken. But the distinction matters: the dilemma I find myself facing is: do I write that extra library or test to make sure things work? Do I take the time to refactor? Is it worth the time?
In those situations, it isn't at all an easy question, unless you know the problem you face requires a one-off software solution with little liability for maintenance.
Yes, I think the point of the story was about being business minded rather than indulging your own programming interests and prowess. Or in other words, the feature creep that you add yourself. This is advice is well timed for me ;)
This is a really cool article in that it shows the transition of one developer into an architect. I think the grief the author is taking in some of the comments has more to do with presentation than content.
The weekends of clever hacks that he mentioned were essential to his development as they are for all of us. The weekend is a good time for clever hacks. If they have useful business implications all the better. Exciting, innovated packages often sprout from a developer's desire for a more elegant, stable, focused, or powerful solution for a problem or a problemset. These innovations should be abstracted into reusable packages and reused.
However, in a business environment, developers need to be focused on solving problems for users. They need to do so in the most stable and sane possible manner. That means that code should be a last resort when a solution has not already been written. If you miss your weekend hackathon, contribute back to the packages that you found helpful. This way, you can get your kicks from clever new hacks and improve several of your existing projects in one fell swoop!
Writing code (and lots of it) is essential to growing as a developer. Unfortunately, it's often a detriment to software projects.
Strictly relying on 3rd-party code without understanding the algorithms and complexities can lead to just as many problems. In my opinion you still better be a very good coder when relying on libraries, just plug and play will fail you sooner than later. I have seen my fair share of this.
When requirements slightly change and you have to adapt a library, suddenly you have to deal with 20k (or more) lines of code and have no idea where to even start. You may just need to use a tiny part of that library but the code is so tightly bundled and abstracted (for good reason) that you have to dig through layers and layers just to make a simple change.
You should at least understand the complexities when relying on 3rd-party code, the Go dependency hell of the game "Haunts" comes to mind (but I don't remember the details, so probably not the best example).
A few additional thoughts:
1. I said "plug and play will fail you sooner than later" -- for most startups that "later" never happens or is not of concern. How often has a startup's code-base made into an acquiring company's production systems without a complete rewrite?
2. Also, when reading some of these posts, I tend to look at the author's motivation/background. This is a somewhat controversial claim (on HN) -- so it is bound to stir up some interest/pubilicty. And also, this is probably not the worst way to court some new clients ("hey, we write less code and waste less of your money"). But I do believe that the re-use approach would be well-suited for short-lived marketing campaigns, as opposed to some other software -- think limited scope and fixed requirements. I'd do the same if I had to work on several campaigns that are probably all similar to a degree.
I think there can be good reasons to choose mature library that solves complex problem (even if you don't understand the code) instead of writing your own code.
I find writing a simple wrapper around big libraries a good practice, it should limit the external library features to what you really need, give you more control on how it's used and allow to switch to other library or even write your own code with much less effort.
This is spot on. Every time you solve a problem without writing code, you avoid possible bugs, future maintenance, and legal issues, and you don't spend time. The second-best code, after code you avoided writing, is code you can delete and as a side effect solve a problem. The less code, the better.
Those are certainly valid points, but I can't help but feel like the OP is going down a slippery slope, and will soon start contracting out coding work to 3rd party, which would then comes back full of bugs and doesn't mesh nicely with existing architecture, thus requiring full-time maintenance from internal staffs anyway.
I can see how you would have come away with that impression.
We produce a lot of code, so much in fact that it didn't even occur to me to state the value in doing so. We definitely do and will continue to keep a talented team busy.
After fiddling with gnunet for too long I'm wondering if the code you don't write will or will not solve the NSA spying problem. I'm in the will not camp so far because gnunet isn't working, and even if it connected to some peers I wouldn't know how to verify my anonimity. They also say something like you might be protected from the law if you click Y here. But I don't want a not guilty verdict, I don't even want to go to trial.
Working as one of two programmers at a startup has really reinforced this for me. As a student and even when I worked at BigCo, I loved taking the time to do things myself, do things Right (with the capital R), and so forth. Now, since I'm surrounded by business people, I'm thinking more in terms of value-provided, not cool-hacks-provided. It's made me ship better things a lot faster and make more people happy. And, really, that's the end goal.
I don't think that too many people like the feeling that their work is going to be useless. On the other hand, if you don't have a larger overview of a problem domain it can be difficult to feel that you're making progress doing anything other than optimising and abstracting.
On the other hand there are reasons why the Linux kernel runs dramatically better designed than Windows.
This really resonates with me. I'm having a terrible time getting high quality code from my team. Software is expensive to develop, and as a tech company we always try to solve every problem with code first. I'm going to make more of an effort to think about our problems beyond the lens of code, thanks!
Most feature requests arrive from a user telling you how they think you should solve some other problem. If you can figure out the real problem and solve it better, that will be an improvement over delivering the exact request as given. (If you can't solve the real problem, though, or you misunderstand it, that's worse.)
For example at one company I was asked to speed up a report. The problem was that it was running too slowly and was timing out in the browser. Instead of tackling that fun optimization challenge, I built a feature that would cause any report that took more than a minute to run to be emailed to the current user. My manager said that he received more thank yous for that feature than for everything else the team had done in the previous 6 months.
At another company I received a request to add a feature that would prioritize pushing specific pieces of data to the website. (We'd had some stability problems, and they had no visibility into what was happening.) I knew that adding this prioritization feature would further destabilize the data transfer logic that I was trying to make more robust, talked to my manager, and refused the request. The senior executive requesting the feature tried to get another co-worker to do it instead, that one asked me innocently how to go about it, I got him to push back. Several months later I got enough of a break from other projects to consider the prioritization feature and asked the executive whether he still needed it. His response? "It has been months since data took more than 5 minutes to get to the website, I'm fine."
Also it can help to generalize your solution. At a third company I built a reporting system where instead of just plugging inputs, every form field could template the SQL that was being used. So a report could also generate drilldowns of itself, and you could combine these in a very flexible way. After a while over 2/3 of the special report requests that I got could be immediately resolved by showing that it was available if you combined two features that had been added for other users doing something else. (My turnaround time for other requests tended to be under 2 hours - and the features, documented, were available for anyone who needed them.)
Programmers do not provide value by writing code. We provide value by solving problems more quickly and cheaply than the alternative. The better you solve problems, the more value you provide.