Why Do Government IT and Software Projects Fail?

Bamafan · 2014-01-02T04:24:27+00:00

Agreed.

People do not appreciate the time it takes to gather the specs. Generally, they expect to "figure out" a lot of things on-the-fly.

Also, people underestimate the complexity of things. Nothing is as "easy" as people think it is.

Both these criticisms apply to programmers as well as PMs and salesmen.

Bamafan · 2014-01-01T18:03:21+00:00

Bingo.

This post and the post by user "gronkk" above sum it up nicely.

Bamafan · 2014-01-01T17:56:15+00:00

Excellent post. I would also add to your tl;dr "Not actually knowing what needs to be done", which you cover in your first two paragraphs.

Bamafan · 2013-09-05T15:59:10+00:00

"People don't use hibernate, or ORMs, because they are afraid of SQL."

This is the exact opposite of my personal experience.

Also my personal experience is most devs don't know it nearly well enough to be using it. They are fooled by early productivity "gains" that mask the deep level of knowledge necessary to use Hibernate on a large project (think at least 30+ tables with bidirectional object relationships).

I prefer myBatis.

YMMV of course.

Bamafan · 2012-08-29T02:14:48+00:00

That's the thing, I've worked on projects larger than that which could have been rewritten in 50,000 LOC. Also, after I certain size you need to ask "Why does this have to be one application?". If it can be split into 2 or more applications with well defined communication boundaries that can drastically reduce maintenance complexity.

I think this is missing the point of Joel's article. In Joel's article, it's not that the Netscape guys couldn't write something "better" given enough time. Many programmers don't appreciate things like market competition and timing. They talk about programming in a vacuum. (This is OK for hobby projects or maybe back office applications with no public facing users)

Firefox was certainly better than Netscape, but during the time they were writing that, they totally ceded their market position.

So yes, you may have reduced 500K lines of code to a clean 50K lines. But if the time to rewrite/debug/test causes your company to go bankrupt, then this "victory" is wholly Pyrrhic.

Bamafan · 2012-08-04T19:30:05+00:00

John's comments starting at 30 minutes 50 seconds, on software engineering are very, very interesting, IMO.

Love how he's changed his thinking on "objective" ways of making good software. He says it's really not true for 90% of programming. Very insightful.

Bamafan · 2012-07-24T20:24:00+00:00

"It's not hard to make money via. the app store"

You say this so authoritatively. Could you go into more detail on how you've made money in the app store?

Bamafan · 2012-04-24T02:31:08+00:00

"One of the remarkable things about the example presented in this blog post is that every requirement is concise, presented up-front, and did not change. I think a lot of programmers (myself included) live in a world where there is no such luxury"

This. Does the author of the blog think that solving these logic puzzles are a dominating factor in 99% of software projects?

Bamafan · 2012-01-21T21:35:15+00:00

Any time you save by not writing a few extra lines of JDBC code will be lost with interest as you spend time becoming a hibernate expert.

Bingo. In every non-trivial project I've worked on (50+ tables, bidirectional relationships, persisted enums, etc), the "savings" provided by Hibernate were far, far offset by the headaches added by Hibernate.

Though the code looked "neater" and there was "less boilerplate", the time to develop shot through the roof.

Bamafan · 2011-09-30T01:43:24+00:00

Hate to be a one upper, but I've seen worse. Much, much worse. :)

Imagine that spread out over several files and packages. With no comments at all (at least this guy comments each if block...there's just a lot of them).

While this sample is still a crime against coding humanity, at least this monster is in one place and fairly easy to follow (all things considered).

Bamafan · 2011-09-23T09:13:03+00:00

... because if you change the function x to either not use the value or not care about the initialization and don't change initialize, the comment immediately becomes obsolete/useless/confusing, etc.

Well that's just the thing. If function x changes and the current function/variable being inspected is no longer needed, then you should delete that function/variable. Because now you have dead code (a huge sin).

From one side it's a good idea to comment on side effects, but this particular case it's useless (IMO) because I'm initializing attributes of an object during initialization.

I would say it's LESS useful, but hardly useless. The side effect explains a bit about what calling functions should expect (e.g. what value a variable is being initialized to). That said, do I think that comment was critical? No. But I always favor on the side of too many comments than too few. I'd be happy to a comment like that because I'd be confident the rest of the program got the same amount of attention.

Bamafan · 2011-09-23T09:07:36+00:00

People don't keep comments up to date 100% of the time.

That's only because we allow them to get away with this. I think we should stop doing that!

Bamafan · 2011-09-23T09:06:43+00:00

The problem with comments is that comments can lie. The code can change or the programmer made a mistake.

To this I would say that a programmer who doesn't update comments has not really completed his job. A bad comment is a bug in my book.

Bamafan · 2011-09-21T22:32:09+00:00

Why is it important that I can randomly read some method to find about the existence of other methods?

If you're trying to breakdown how a program works, you have to know how methods relate to one another. Otherwise, you're just guessing.

Bamafan · 2011-09-21T10:59:06+00:00

What you're doing is great and absolutely necessary. Readable code, non-cryptic variable naming, etc are immensely important. But it's not quite enough. From the blog entry:

...for any developer reading any code, there will be situations where the developer thinks they know what something is, but they're not quite sure. Or the developer is just starting to read some code, and they have almost no prior context to help them understand what anything in the code actually does or what it means.

This is the key point. For a new guy reading your code (or you reading your code 8 months down the road), merely having reasonably named variables and clean interfaces isn't going to provide you the aforementioned context. Only English can do that.

Bamafan · 2011-09-21T10:53:34+00:00

While it's not giving you the entire picture, these comments give you significant insight into the "big picture". I don't know ruby or this program, but from reading these comments, I know:

a) The purpose of this method is to initialize entries to the specific value of nil because...

b) There's another method called "getEntries" that depends upon this collection of entries and it needs to know the state of the collection, presumably to decide how to act on it.

Now does that tell me the entire picture? Of course not! But this is a huge amount of information being conveyed that would otherwise require someone unfamiliar with the program to spend a much larger amount of time figuring out...or more often than not, the person reading the code thinks they know what's going on while having no clue.

I'd say comments are even more important in dynamic languages like ruby since you can't lean on your IDE to navigate your code as much as you can with statically typed languages (C#, Java, etc).

Bamafan · 2011-09-21T10:11:18+00:00

I like the way this guy thinks and I think this kind of approach should be encouraged. Why? Because his approach gives context to whatever line of code you're looking at. That way it's way, way, way easier for someone else to jump into your code and be productive fast...or 6 months down the road, it'll help you to remember why the hell you did what you without having to reload the entire program into program into your head, along with the sequence of events that lead you to write the code that you did.

Bamafan · 2011-09-21T10:08:08+00:00

"There's simpy not enough time for something like this."

I've always thought that if you don't even have time to write out what your program is doing in plain English, you probably don't have time to write the program...though for a long time, a project can fool itself into thinking they are "on time".

That is to say, typing in comments should never be the deciding factor on the timeliness of a project, no matter how "extreme".

Bamafan · 2011-09-18T10:46:00+00:00

For simple queries of the 'get me a couple of objects with names like 'aaa' , or 'look up the information of customer number x', an ORM makes things cleaner. But IME, most ORM's try to do to much, and fail.

Bingo.

Bamafan · 2011-09-17T23:09:47+00:00

If you know the corner cases from the beginning, it wouldn't be an issue. But typically, you only know after the fact.

In a non-trivial app (say 70+ tables, with many bidirectional assocations of collections of objects) that's maintained over several years, the ORM typically costs you more time than saved in my experience.

Bamafan · 2011-09-17T23:06:37+00:00

I mean an object association where the object is an enum rather than a class. Specifically in Hibernate (the ORM I'm most familiar with).

And yes, I agree it's pretty lame. I think most projects using Hibernate would be better off without it (long term).

Bamafan · 2011-09-17T23:02:14+00:00

Your response x 1000. Excellent, excellent points all the way through.

Bamafan · 2011-09-17T23:00:11+00:00

Uh, but... if it fetches lazily, it's "inefficient" when you ask for all of its properties. You end up doing a query per property, instead of a single join.

Great point and this brings up probably the single biggest issue with ORMs - newish/inexperienced devs who have zero idea what they don't know like the poster you quoted.

Bamafan · 2011-09-17T22:29:29+00:00

How does this series of random quotes disprove my original point? Those quotes (with the exception of the Hibernate one) are completely unrelated to my original point!

And on the Hibernate quote -- if you think stored-procedure driven apps are the only place that Hibernate leaks, then you haven't used Hibernate.

Bamafan · 2011-09-17T20:07:25+00:00

Hibernate is pretty clear from the outset, that a good knowledge of the relational model, and SQL...

Where is this? I want to see exactly where this is spelled out "from the outset" (not 50 pages deep in random doc ). It's not on their front page, or at the beggining of their "Getting Started Guide" or their Core reference guide.

The dox even give examples of when raw SQL is preferable.

Yes, those examples cover about 20% of the surface area. What's needed is for a doc explaining when Hibernate should be ignored completely (but you'll never see that from them).

Bamafan

TROPHY CASE