Down with Systems Analysis
System analysis.  Sounds like an exciting career.  Lots of positions as programmer/analysts are offered in the job lists every day.  But what is it?  The textbook says it's about solving problems.  That's interesting.  The manager will hire you because you are smart and can solve problems.  You will come up with solutions and program/implement them.

But when you get down to the details, it's boring.  You don't really solve problems.  You repeat design patterns.  You talk in vague language about methodology, but you never state clearly what you mean.  System analysis is inseparable from project management, software engineering, and office politics.  They are all one and the same.  Sure, you can distinguish a half dozen stages of the software life cycle, but beyond that it's all clouds.

I posted this as a goodbye message on a forum at Keller Graduate School of Management, a subsidiary of Devry. I was persuaded to go for my Masters degree with the promise that it would help me get my dream job. The admissions advisor promised me the courses would be hands-on. Systems Analysis was anything but.

As you will see, I have come to hate with a passion every tool, technology, or methodology that restricts the developer and requires scaffolding. You have probably heard that Objects Suck. You may have seen how fragile Agile is. You possibly have heard of the term "boilerplate code". This are all part of the same problem: business loves repetitiveness because it looks like work. College loves vagueness because it looks scholarly. I hate it all.

I have never experienced Agile as an employee, but from a student's perspective, I can tell you it's not clicking.

Here is what I posted:

I am through with this course and this school. I am definitely quitting. I do not expect to pass this course due to the arbitrary grading policies of this professor. He's not reading the same document I am reading. My use case stories were in table format. His grading comments told me they needed to be in table format. I take it he is saying there were not. I don't know what document he is reading, because I used all the formats and templates required.

I am posting his grading, and yes I dare post them here. I have no conscience. I will even post this on my own blog:
http://jasonc65.livejournal.com/

I will be rude and blunt. I hate systems analysis, Agile programming, and everything related. Linus Torvalds never used this Agile mess. I've read comments about overdocumentation, and let me tell you: I think this whole course is an exercise in overdocumentation. I don't get do any programming. I must document until dawn. This top-down approach does not work in practice. Whenever I design a major project, assumptions always are changing during the process. This leads eventually to design from the bottom up and evolving programs over hundreds of iterations (most of which are never released). That's how I do programming at the internship, and that's how I do all personal and academic projects.

Then look on SourceForge. Do you see any groups using Agile there? You don't. Look for Linux kernel documentation, and there are no use case diagrams or UML diagrams. Real programmers don't use this nonsense and fluff, and I will not.

If this is what my learning experience is with this nonsense, then I don't have positive expectations that it will work out well at work. All business courses teach vague fluff. We go through various vague subphases of just one phase: analysis. We haven't gotten to design, and yet we are already doing design and modeling. This leads to analysis paralysis. We are not really following a process, just chaos. We are jumping all over the place. We document redundantly and never stop analyzing, gathering, and proposing. We're doing a course project with milestones that has a rigid structure. This is not agile, it's fragile. And then we get bad grades because our diagrams just weren't exactly like the "course solution". This is clearly a problem that has no right answer, and yet we are graded according to a right answer that doesn't exist.

I don't need courses like this: I never did. I never needed project management, yet they force you to take it or withhold your degree. This is social injustice.

I don't need this treadmill. My experience at Devry has been stressful. My experience at my internship has been relaxing and fulfilling. I don't want go on to be a project manager or a Scrum master. I would suck at that stuff, and the experience would suck for me.

I want to design operating systems, implement protocol suites, build GUIs, devise compilers, and experiment with new programming techniques. I want to make a name for myself in programming. I don't want bosses telling me what to do and how to do it, especially confused bosses who have vague instructions and arbitrary standards.

I also want to do mathematical research and integrate it with programming.

I want to continue with my internship, and I value my free time more than anything else. This school adds no value to my education, only stress. I'm out.

There have never been so many programming languages as now, and I there are some languages I find constricting. Some languages require enormous scaffolding to get done the simplest things and are needlessly repetitive, just like Fragile processes. I like technologies that allow you to whip things up fast, languages such as F#, Haskell, and Scheme. Scrum masters love constricting tools such as COBOL. I hate them with a passion.

There are plenty of programmers with real lives who will tell you they agree with me.
Ted Neward wrote a killer book on F#, and he says Best Practices suck:
http://blogs.tedneward.com/2010/08/10/Death+To+Best+Practices.aspx
Paul Graham also hates Best Practices. As a Lisp programmer, he has no qualms about admitting that some of the best programming is done from the bottom up.
http://lib.store.yahoo.net/lib/paulgraham/onlisp.pdf
This author inspires me to hack in Lisp again.

As for top-down design, some of the worst projects have been designed that way: FORTRAN, ALGOL, MULTICS, IBM System/360, W3C Standards (especially CSS), Obamacare. Some of these systems have been pretty decent but badly marketed. Others just suck. Some are designed by corporations, others by committee. Some of these projects have been slowed down by the addition of programmers.

Another thing: I have never worked as a programmer for a company that uses Agile, but I have volunteered as a programmer for an organization that does not have any need for any of this fluff.

Kreckel, you may have been a programmer, but you have long ceased to be one. You have become another myopic micromanager who does not respect the intelligence of your team. You are irrelevant. Your sympathetic words to the contrary do not convince me otherwise.

This will be my last post in this course. To those who responded to me and were willing to put up with me, I have no hard feelings. I feel sorry for anyone who has to take this course, and I have respect for anyone who is able to survive it and remain sane. For this school and this institution, I have nothing but disdain, and I'm getting on with my life.

My grading comments:

Milestones 1,2 (grade: 16/80)
Jason, in the RFS you are not stating the problem. The real problem is that information needed in the field is not there. This is based on the interviews. The Problem system matrix looks should state problems. OS Issues doesn't tell us what the problem is. Why is Internet Explorer a problem? I can give you data loss but the loss is from missing manual notes. There are actually about 4 problems. On the Problems, Opportunities, Objectives Matrix each problem should be listed with its own causes and effects. You need to indicate what the cause(s) is and what the effect(s) are. If you have 4 problems on the Problem System matrix you should have 4 here. Context Diagram doesn't look anything like I showed you in the iConnect session last week. You need actors and the functions the system needs to perform. List of requirements needs to be more specific. How do I make a reliable system? That doesn't do anything. What we need here are the needs. What the system needs to do. Compare your solution to the revealed solution (see solution tab).

Milestones 3,4 (grade: 46/80)
Jason, For Milestone 3 Use-Case glossary should have 15 Use-case names. It should be in table format with three columns showing Use-Case Name, Use-Case Descriptions and Participating actors - similar to how I showed you in last week's iConnect session.. Use Case Model is a graphic picture of those same 15 broken down into two subsystems as I displayed in the iConnect session last week. Use-case Narative should have 6 steps and those steps should be split up as to Actor Action and System Response. This shows back and forth action between the system and the user. You only had to do one of these. For Milestone 4 Entity/Definition Matrix should have 9 entities. The Context Data Model, the Key Based Data Model and the Fully Attributed Data Model should have 9 tables. Each is build upon the other. The second table should have Primary keys. The Fully Attributed data model should have all attributes listes. You obviously did not view the iConnect recording from last week. I got you started on all of these deliverables. Compare your solution with the solution revealed in your course. Also, please review the iConnect recording to see how this is done.

re: Milstones 3,4
There were no instructions saying how many use cases I had to have.
My glossary was in table format.

I did review the iConnect session. I skimmed it, though.

No instructions said how many steps my use-case narratives I should have.

Instructions didn't say how many entities I should have.

My second data diagram did use primary keys.

The instructions are not clear as to how much detail is too much or too little. I can't take this from you or this course. I need specific instructions, not vague. I need objective grading standards, not subjective (you say after the fact that 7 is not enough). This is not fair, and I am quitting school. This time, I mean it.

(Comment on this)

*nix: the Good, the Bad, and the Ugly
The Unix operating system concept is ugly.  Is it user-friendly?  Well, not exactly, but if you like using the terminal and need a relief from point and click hell, then it may very well seem friendly to your user needs, if not over-indulgent.  If it is more important to you that commands be short and easy to type than speak English, if "ls" is therefore better than "list", so be it.  Unix is like Perl: you don't have to be fluent in it to use it, but like Perl it is also ugly.  In fact, Perl was written as a very powerful Unix tool that was abstract enough that it could easily be ported to other OS's.

Is Unix programmer friendly?  Well, it depends on the type of programmer.  There are two: hackers and developers.  *nix is very friendly to developers in many ways.  It offers many tools, some of which are easy to use with fluency, and others like Perl which are easy to use even without fluency.  There are many higher-order object oriented and functional programming languages that have been originally designed for the Unix console.  Microsoft has made some good moves towards developer-friendliness but will never give the developer the power of Unix.

But is Unix friendly towards hackers?  Absolutely not.  If you are a novice who wants to start out in programming, you have many choices of operating systems and tools to start out in.  Although not as novice-friendly as Visual Studio, the Unix programming environment cannot be said to be intimidating.  But suppose you're not content to just develop applications.  You want to hack the kernel.  Maybe you dream of developing a new killer OS that will make *nix obsolete.  In that case, Unix is very unfriendly and frustrating to work with.  Yes, Unix is praised as a very hacker-friendly operating system, but only because it is less hacker-unfriendly than the alternatives.  Most OS's are proprietary systems, where the author does not want you to hack into their kernel, modify the source code, and share the hacks with others.  They may even use DMR to lock out hackers.  In fact, the source code is not available.  With some "nixes, at least you can get the source for free and are not limited by onerous licenses that prevent your modification and sharing.

But how do you modify the source code?  It is written in C, but is it enough to just be fluent with C to understand the source code?  Wrong again!  You have to be fluent in a variety of tools that are used in the Unix environment, one of the ugliest of them being "make".  Almost every kill app or enterprise compiler built on Unix uses make files.  These make files usually are designed to make the management of large hierarchies of source files and libraries possible.  They are very difficult to work with if you are a novice C programmer who has just learned the language itself.  Makefiles are an ugly assortment of variables, conditional statements covering tedious cases, conditional targets, phony targets, and options.  There is also the C preprocessor.  The kernel developers love the C preprocessor and its system of macros.  They just love to throw in a constant or a macro wherever they feel like instead of doing the actual coding.  You have to chase ugly #defines throughout your source hierarchy, and they can easily be broken.  Their comments are not too helpful; neither are their READMEs.  You also have to know about diff and patch.  Developers love to save their changes to programs as patches in order to avoid copying large files.  They also love tarballs, and you have to remember just the right options to use when you want to extract.  In fact, usually, you will download the source of a typical project as a tarball and then extract it to your favorite directory.  Fortunately, the GUI usually provides tools to make extraction novice friendly.

Once you have found that mirror, downloaded and extracted the source archive, what is the next thing you want to do?  Maybe you would just like a clean compile.  You do this with ./config and make, but the result will probably be unusable.  You can type "make install", but are you sure?  You can make your system unbootable, you know.  You should only play around with the kernel if you have a Knoppix CD and have nothing valuable on your hard drive.  There is a detailed list of instructions on HowToForge for compiling your kernel in Ubuntu, but you still don't feel safe following them through.  In short, compiling your kernel is unsafe, intimidating, and not easy for novices.

In fact, even if you have 20 years of experience as a senior C++ developer, kernel compilation is extremely intimidating.  The Unix Haters Handbook describes all the evils of Unix from the very get-go.  Interestingly, Unix was designed as a compact operating system, as in bytes, not cubic feet.  The original Unix could have fit inside your cell.  It could have run on an obsolete Apple ][, TI 99, TRS-80, take your pick.  It actually started out as an 8-bit OS.  In fact, there is virtually no architecture limits because it was designed first in B, then in C.  And it was designed for playing video games.  The original hackers were probably doing things on the job they shouldn't have been doing.  AT&T was holding on to the rights to the system, even though they originally had no intention of  using it.  Consequently, it was being bootlegged frequently, and even universities were getting it illegally.  Then many companies turned it into various proprietary systems that were really no less buggy than Window$.  Also, the hackers were splintering up into various groups with their own versions.  These versions had various names, usually ending with X: Xenix, Posix, X as in X-Windows, and now Linux.

(2 Comments |Comment on this)

Starting Out
This is my first blog entry.  I have never really had a blog before.  My journal used to consist of one entry that probably sucked.  I decided to delete that entry and start from scratch.  This time, I will just focus on my interests, which include:

• mathematics
• theoretical physics
• computer programming
• miscellaneous
  • theology
  • travel
  • classical languages (Latin, Greek, Hebrew)
  • politics and economics
  • fantasy (Lord of the Rings, Harry Potter, Narnia, Oz, etc.)

I admit I used to entertain some radical ideas.  I have become more realistic.

Currently, I have my unstarted career on my mind.  I have been withdrawn from school and back.  I have believed that education was the key to getting a job.   I am not so certain of that anymore.  When my career adviser suggested internships, it was news to me.  Now it seems that experience is more critical than education or anything else when it comes to job hunting.

Yet on further reflection, experience must not be everything.  How many politicians have been elected in spite of lack of experience relative to some reasonable alternatives?  John McCain had much more experience than Obama.  Perhaps career politics is the only field where experience is not required.  With experience comes reputation, and that reputation says a lot about you.  Do you hire someone with a bad reputation just because of a vast experience?  I certainly don't make decisions that way at the ballot box; if I believe a politician is corrupt, his experience to me is a negative.  I would prefer a politician who has had no years of experience at raising taxes and killing opportunity.

Something must also be said about relevance.  My experience as a library page is so irrelevant to my field that it does not qualify for even data entry.  When it came to Vice President, Biden had vastly more years than Palin, yet governorship is clearly more relevant to the position sought than legislature.  Yet the media hyped up Biden's experience as if that were everything.  If I were applying to a Java Developer position, having had 20 years of .NET experience, and my chief competitor had just 1 year of Java experience, I would not be surprised if I were rejected and my adversary accepted instead.  Suppose I had been in favor of Microsoft's monopoly and my opponent touted open source; I would be even less surprised.  Yet if I were running for election and not appointment, I just might be able to dupe the stakeholders into voting for me on vague promises of hope and change.

I guess what really matters the most is skills and the ability to prove them.  And the less employers have access to references, which may give some indication of actual reputation, the more they rely on experience as the absolute benchmark that decides against all else.  I do know for a fact that my current boss is not permitted by the company to give professional reference on my behalf.

Imagine if the 2008 election were a corporate hiring decision.  Sarah Palin would have been given a slight consideration in the form of a brief phone interview, because her executive experience would have gotten the recruiter's attention.  But she would not have made it any further.  Questions about her daughter would not be asked because they would be unprofessional and illegal.  Biden would have made it to the interview because his experience is vast.  But his references would have looked bad.  McCain would also be interviewed, but he would be faced with tough questions such as how to deal with terrorists who are using hostages as weapons and exploiting rules of engagement to gain tactical advantage on the battlefield.  He would be asked to give an example of a decision he later regretted; surely, campaign finance reform and amnesty would come to mind.  He would also be asked what he had learned from that experience, how he will act to undo the damage, and how he would act differently if faced with a similar situation politically.  As for Obama, his resume would have been deleted in one second.  Sure, he has a degree, but it would not matter, since he would have bumped against the zero experience barrier.  His career advisor would be telling him to stay in the job he was in longer.  After all, one doesn't rise from the mailroom to CEO overnight.  The candidate we would have eventually selected for President would meet all the most vital qualifications necessary, including being tough on illegal immigrants, being a Constitutional originalist, supporting America's exceptionalism, taking pride in serving the customer which in this case is the taxpayer, and having a strong background in economics.  A military experience such as McCain's would have been a plus.  But alas, politics being what it is, we are stuck with what we got.

The economy is mystifying.  There have been times in my life where I was more positive, because I had better turns of luck.  Jobs can be suddenly hard to get, and one wonders why.  The economics textbooks will tell you to believe in capitalism because it works, and that when politicians interfere, they make it worse and not better due to the law of unintended consequences; but they will never be able to explain your particular situation or why it is bad.  Things can also suddenly boom again.  For a while, I was not finding internships; now I am finding a slew of them posted on a few websites that had previously been stuffed with regular jobs just so that they wouldn't have nothing to show for the bad situation.  Also, job boards are starting to report new records of job openings.  For the past three years, I have been dreading what might become of the political changes that were being foisted on us.  I had hoped that the Tea Party movement would start to undo the damage and have enough effect to start the recovery.  I have been fed up with the media's pretending that the recovery already occurred, when anyone with common sense can tell that if there are no jobs, there is no economy.  In 2011, I am seeing some signs of hope, but whether it's the true recovery, only time will tell.  The proof is in the pudding.

Enough about politics.  In my next entries, I hope to give some amusing thoughts that have been accumulating over the years, having to do with the noncontroversial topics of my interest, especially the top three.  One thought that is news to me is that blogging might enhance my job search.  It is a vague hope but worth trying.  Meanwhile, I'll see how my orientation for the internship position turns out.

(Comment on this)