Software Development
There are 20 entries for the tag
Software Development
Disclaimer: these opinions are my own and don’t necessarily represent the opinion of any person or institution who are not me. The topic of sexism in the software industry has flared up recently. This post by Katie Cunningham (aka The Real Katie), entitled Lighten Up, caught my attention. As a father of a delightful little girl, I hope someday my daughter feels welcomed as a developer should she choose that profession. In general, I try to avoid discussions of politics, religion, and racism/sexism on my blog not because I don’t have strong feelings about these things, but I...
Eric S. Raymond in the famous essay, The Cathedral and the Bazaar, states, Release early. Release often. And listen to your customers. This advice came from Eric’s experience of managing an open source project as well as his observations of how the Linux kernel was developed. But why? Why release often? Do I really have to listen to my customers? They whine all the time! To question this advice is sacrilege to those who have this philosophy so deeply ingrained. It’s obvious! Or is it? When I was asked this in...
On Twitter yesterday I made the following comment: We're not here to write software, we're here to ship products and deliver value. Writing code is just a fulfilling means to that end :) All I see now is blonde, brunette, redhead. For the most part, I received a lot of tweets in agreement, but there were a few who disagreed with me: While I agree in principle, the stated sentiment "justifies" the pervasive lack of quality in development Doctors with this mentality...
Every now and then some email or website comes along promising to prove Fred Brooks wrong about this crazy idea he wrote in The Mythical Man Month (highly recommended reading!) that there is no silver bullet which by itself will provide a tenfold improvement in productivity, reliability, and simplicity within a decade. This time around, the promise was much like others, but they felt the need to note that their revolutionary new application/framework/doohickey will allow business analysts to directly build applications 10 times as fast without the need for programmers! Ah yeah! Get rid...
The design is never right the first time. Nor is it usually right the second time. This is one of those key lessons you learn over time building real software, and is the source of one of the chief complaints leveled at the Waterfall methodology for building software, which puts heavy emphasis on getting the design right up front. We have to define “right” in this case. If by “right” you mean perfect, then I don’t think the design is ever right, as I’ve argued in the past that there is no perfect design. Recently, this lesson...
Recently, Maxfield Pool from CodeSqueeze sent me an email about a new monthly feature he calls Developer Faceoff in which he pits two developers side-by-side for a showdown.
It’s an obvious attempt to gain readers via an appeal to vanity of the featured bloggers who have no choice to link to it. Brilliant! :)
Seriously, I think it’s a fun and creative idea, but I have no credibility in saying so because I’m obviously biased being featured alongside my longtime nemesis and friend, Scott Hanselman. So check it out for yourself.
Some of my answers were truncated due to the format so...
Here’s the dirty little secret about being a software developer. No matter how good the code you write is, it’s crap to another developer. It doesn’t matter if the code is so clean you could eat sushi off of it. Doesn’t matter if both John Carmack and Linus Torvalds bow down in respect every time the code is shown on the screen. Some developer out there will call it crap, and it’s usually the developer who inherits the code when you leave. The reasons are many and petty: Your code uses string concatenation in that one method rather than...
It is a sad fact of life that, in this day and age, arguments are not won with sound logic and reasoning. Instead, applying the principle of framing an argument is much more effective at swaying public opinion. So the next time you try to make headway introducing Test Driven Development (or even simply introducing writing automated unit tests at all) into an organization and are rebuffed with... Don’t bring your fancy schmancy flavor of the week agile manifesto infested “methodology” here kiddo. I’ve been writing software my way for a loooong time... You can reply with... ...
One surefire way to sound really really smart is to invoke a law or principle named after some long dead guy (an alive guy is acceptable too, but lacks slightly in smart points).
This realization struck me the other day while I was reading a blog post that made a reference to Postel’s law. Immediately I knew the author of this post must be a highly intelligent card carrying member of MENSA. He was probably sporting some geeky XKCD t-shirt with a lame unix joke while writing the post.
Well friends, I admit I had to look that law up, and in...
In the The Mythical Man-Month, Fred Brooks highlights an eye opening disparity in productivity between good and poor programmers (emphasis mine). Programming managers have long recognized wide productivity variations between good programmers and poor ones. But the actual measured magnitudes have astounded all of us. In one of their studies, Sackman, Erickson, and Grant were measuring performance of a group of experienced programmers. Within just this group the ratios between the best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements! Robert Glass cites research that puts this...
System.IO.Path
How often do you see code like this to create a file path?
public string GetFullPath(string fileName)
{
string folder = ConfigurationManager.AppSettings["somefolder"];
return folder + fileName;
}
Code like this drives me crazy because it is so prone to error. For example, when you set the folder setting, you have to remember to make sure it ends with a slash. Having too many things to remember makes this setup fragile.
Sure, you write some code to ensure that the folder has an ending slash, but I’d rather let someone write that code. For example, Microsoft.
The .NET framework is definitely huge so it can...
I don’t know about you, but every company I’ve ever worked at had a Fort Knox like system in place for deploying code to the production server. Typically, deployment looks something like this (some with more steps, some with less): Grab the labeled (tagged) code from the version control system. Obviously, ensure that the application must compile. Another developer other than the author must review the code on some level and sign off on it. Automated unit tests must pass. If they exist, the automated system and integration tests must pass. The QA team tests the...
We often hear that the current state of software development is still dysfunctional. Scott Rosenberg recently wrote a book to that effect called Dreaming In Code. He takes takes a look at the question Why is software so hard? According to Scott, Software developement’s history is marred by poor quality, missed deadlines, and cost overruns, primarily due to a persistent dysfunctional culture. And he’s talking about software written by companies who are in the business ogf writing software. Well if software written by software companies is so bad, how bad is the software written by hardware companies? Very bad. I’m sure there are a few exceptions,...
Jeremy Miller believes that among the various beneficial and important qualities a codebase can have, the single most important quality of code is maintainability. I totally agree, having spent many hours maintaining legacy code written years ago as well as code I wrote a week ago. As soon as a line of code is typed on the screen, it becomes legacy. You are now maintaining that code. Enterprise software systems change. Business rules change, technology platforms change, third party dependencies are upgraded. ... Enterprise systems typically aren’t replaced because they stop working. The end of life cycle for an...
In a recent post I talked about how good design attempts to minimize the impact of changes to a system, often through Design Patterns. When used appropriately, Design Patterns are a great tool for building a great design, but there is an important caveat to keep in mind anytime you apply a pattern. A Design Pattern might minimize the impact of one kind of change at the expense of amplifying another type of change. What do I mean by this? One common pattern is the Abstract Factory pattern which is often manifested in .NET code via the Provider Model...
We’ve all been there. Your project stakeholder stands in your doorway with a coffee mug in hand and asks for one more teeny tiny change. Yeeeaaah. It’d be great if you could just change the display to include the user’s middle name. That’s pretty easy, right? No problem! Let’s see. I’ll just need to modify the database schema to add the column, update several stored procedures to reflect the schema change, add a new property to the User class, update the data access code to reflect the new property, and finally update the various user controls that render or take in input...
In the essay entitled Hold the Mayo, 37signals points out the obvious fact that most surveys ask users what features they want added to a product. They rarely ask what features they want removed. I have in the past asked users for permission to remove features, but I've never taken the extra step of asking users, which features would they like removed. So here I go. Which feature(s) would you like to see removed from Subtext? I think a natural response I will receive is the question, Why would you ever want to remove a feature? Features have many...
Jeff Atwood writes a great post about The Last Responsible Moment. Take a second to read it and come back here. I’ll wait. In the comments, someone named Steve makes this comment: This is madness. Today’s minds have been overly affected by short attention span music videos, video games, film edits that skip around every .4 seconds, etc. People are no longer able to focus and hold a thought, hence their "requirements" never settle down, hence "agile development", extreme coding, etc. I wonder what methodology the space shuttle folks use. You shouldn’t humor this stuff, it’s a serious...
Jeff Atwood writes a great rebuttal to Steve Yegge’s rant on Agile methodologies. I won’t expound on it too much except to point out this quote which should be an instant classic, emphasis mine: Steve talks about “staying lightweight” as if it’s the easiest thing in the world, like it’s some natural state of grace that developers and organizations are born into. Telling developers they should stay lightweight is akin to telling depressed people they should cheer up. Heh heh. Jeff moves from a Coding Horror to a Coding Hero. Now while I agree much of it is religion,...
I’m not proud of it (well maybe just a little), but I once created an insane build process once. If Pat (who maintained the build after me) posts in my comments, he’ll tell you about it. Take a stew of a proprietary microcomputer flavor of Fortran written in the 70s by a programmer most assuredly clad in polyester, churn it through a Visual Basic 6.0 preprocessor that spits out Fortran 90 code, all the while correcting memory bound issues, mix it together by compiling it with a custom NAnt fortran compiler task, and voila!, 20 or so compiled Win32 fortran...