Hands down this is the best article I've ever read about software development, thanks a lot for sharing.
Things I've learned about writing software after 12 years
91–100 of 122 posts
Re: Things I've learned about writing software after 12 years
#92There's really one issue here. Budget. You want two pairs of eyeballs on everything as you write it? Okay. Pay two guys. You want complete test coverage? Okay. Can take as long as writing the code itself. Maybe more. You want full documentation? Okay. Guy can't spend as much time on coding. You want new APIs to be included? Okay. Guy's got to read docs and try samples. Less time. What I've seen is you always end up w…
The real issue is communication, not necessarily budget, as the reason software projects I've been exposed to fail. A project manager can only get you so far, especially if the team dynamic is rotten or even sub-par. Management is never really the answer to me, even saying that as a coder who splits time as a manager. At the end of the day, if your team doesn't have the right dynamic -- soft skills or otherwise -- I…
This is very true. I hadn't touched on the cultural aspects of why things get managed poorly.
One thing to note is when the guy calling the shots is not a programmer. It's simply hard to see all the things programmers have to do, other than typing out code. It's also hard to see why some guy wrote a bug if you're never the guy who is responsible for it.
Have a look at sports teams. The coaches tend to be ex players, even if at a very low level.
The other thing about manager types is things never go wrong for them in a way that is purely them. When I worked in marketing, I'd never get stuck on a PowerPoint slide for days. Problems were always organizational, and someone else was always involved. Sales guys aren't selling fast enough. Fab guys are stuck with their new process. PR people have the wrong message.
It's very easy as the organizer to just think all the problems are due to other people.
Re: Things I've learned about writing software after 12 years
#93Earlier quoted context omitted.
I guess the other thing is instability of the requirements. Something like grep or uniq are almost perfect because the use case is stable.
When I was still in training, I had the pleasure of participating on a software project to build a "web shop" for internal use at a large IT company. It was a pleasure insofar I was only a trainee and did not have to deal with the politics and all that. One day, a week before the first part of the web shop was scheduled to go live, the programmer I was working for came back from a meeting. Usually, he was pretty laid…
The thing with programming and abstract stuff is it's very hard to know what makes the problem much harder. And you definitely won't have intuition for it if you haven't programmed.
For instance, it's easy to prove that there's an infinite number of prime numbers. There's no biggest prime, because if there were (hand-wave proof coming) you could multiple them all together, add one, and have another prime number. Easy right?
Now tell me if there's also an infinite number of twin primes, ie pairs of prime numbers separated by two.
Here's a good xkcd: http://xkcd.com/1425/
Re: Things I've learned about writing software after 12 years
#94There's really one issue here. Budget. You want two pairs of eyeballs on everything as you write it? Okay. Pay two guys. You want complete test coverage? Okay. Can take as long as writing the code itself. Maybe more. You want full documentation? Okay. Guy can't spend as much time on coding. You want new APIs to be included? Okay. Guy's got to read docs and try samples. Less time. What I've seen is you always end up w…
The real issue is communication, not necessarily budget, as the reason software projects I've been exposed to fail. A project manager can only get you so far, especially if the team dynamic is rotten or even sub-par. Management is never really the answer to me, even saying that as a coder who splits time as a manager. At the end of the day, if your team doesn't have the right dynamic -- soft skills or otherwise -- I…
Very true. Except that budget is a limiting factor when it comes to communication as well. A team is going to put much less energy and thought into communicating if they have their hands full.
Re: Things I've learned about writing software after 12 years
#95There's really one issue here. Budget. You want two pairs of eyeballs on everything as you write it? Okay. Pay two guys. You want complete test coverage? Okay. Can take as long as writing the code itself. Maybe more. You want full documentation? Okay. Guy can't spend as much time on coding. You want new APIs to be included? Okay. Guy's got to read docs and try samples. Less time. What I've seen is you always end up w…
This also has implications for your career development as a programmer. I've been working at an outsourcing shop for the past two years and have barely grown as a programmer.
If you work at a place where the client isn't willing to pay for good quality software you will never learn how to make software the right way , simply because there is no time to do it the right way.
Re: Things I've learned about writing software after 12 years
#96It was a good rant until he encouraged writing a test after writing the code to be tested :(
As a developer also with 12 years experience, I implore you to write your tests first. Otherwise your organisation will almost inevitably end up with brittle tests & it will often cost more to patch up the tests when they break than the cost of the possible increase in genuine bugs.
I don't necessarily espouse slavishly adhering to TDD (it works for some devs, not everyone) but experience has taught my heart to sink every time I hear someone say "I've implemented the feature, now I just need to write tests."
Re: Things I've learned about writing software after 12 years
#97Re: Things I've learned about writing software after 12 years
#98There's a sentiment in the article I see a lot that keeps coming up these days: "NASA sent a spaceship to the moon with something 100x slower than my computer, so why does it take so long to load a page"? I think it's entirely unjustified. What makes modern software engineering difficult is that it's one of the few engineering disciplines where not only are you making a Boeing 747 fly, and all the parts were made by…
Except that most modern development isn't trying to make a Boeing 747 fly. It is trying to meet a goal that works for most people, with enterpeise development even explicitly throwing out "80% rules", etc.
So most developers are just trying to make a 747 taxi to the end of the runway. Or even just sit there without its wings falling off.
We'll get it to fly in the next version.
Re: Things I've learned about writing software after 12 years
#99Don't forget to thank nazis, who taught you how to build rockets and soviets who showed you that space travel is possible.
Re: Things I've learned about writing software after 12 years
#100We get the software we deserve. Apparently, people aren't ready to spend more money on performance, reliablility and security. When they buy software, they pay the price of a giant ball of mud (if they aren't expecting it to be free!) and they get a giant ball of mud. Simple. You call it insanity, I call it market, supply and demand. Of course, the perfectionists are unhappy about that (being one myself I can certain…
>but you have to realize that this kind of perfection in software costs huge amounts of money Maybe not as much as people think. There are machine-assisted mechanisms for building mathematically perfect software. See Curry-Howard oriented languages like Coq and Agda. It's certainly harder to write perfectly, provably correct programs, but maybe not as hard as most people think. There is also a lot of middle ground in…
The thing about typechecking, though, is that you're essentially specifying your program's behavior twice: Once very detailed in the actual code and once at usually some lesser detail in the types. All the compiler does is checking that these two specifications are consistent with each other. Your types can have bugs too, in which case nothing will help you. What frustrates me about detailed type systems is that as detail increases, difficulty of writing the types will increase and type bugs will become more common. Now, assuming the bugs in your code and types are statistically independent that would still save you a lot of bugs, but I suspect they are not.