What is Wrong with Software Development Today: A Rant by Steven Williams

NOTE: This is a rant, this is only a rant.

A Little History

My first foray into computers was back in 1995 on a Packard Bell Legend running Windows 95. That was back in the days when you had to know how to make batch files, edit config.sys files, and play with IRQs just to get some, read “most”, games to run.

I pretty much lived in DOS. The command  line was pretty powerful and it was from there that I discovered QBASIC. I thoroughly enjoyed learning everything I could about DOS, Windows, and making my own programs. It was an awesome journey every time I turned on my computer.

PackardBell_Force-53CD_486

Fast forward many years, and here I am, a full-fledged software developer with around 8 years experience. It has been a rough ride to say the least.

Not What I Expected

I have had to deal with a lot of very abrasive, and sometimes borderline abusive, people in my professional career. I never imagined I would be dealing with those types first-hand. It definitely takes a toll on me. I’m still learning to deal with challenging personalities but it has always been a challenge for me.

I don’t expect puppies and butterflies, I just expect people, adults, to act professional and not take their frustrations out on the developer (me). I realize that’s unrealistic, but I can dream can’t I?

56d

It Isn’t the People, It’s the Process

I don’t think it is the people as much as it is the process.

Some companies that I have worked for pretty much lacked process. A typical project usually went something like this:

  1. Project “initiated” via an informally written email from my manager
  2. Meeting scheduled to kick it off
  3. Meet to discuss what the project is about, what they need, etc.
  4. Informally “gather requirements”
  5. Design and architect the solution
  6. Design and implement the SQL tables
  7. Start putting code to screen
  8. Test
  9. More code
  10. Test
  11. The “I’m done” moment when I inform my manager and my end-user that we’re ready to “go-live” with the product
  12. As soon as they are told to use the software, it seems that something is “wrong” (typically perceived wrong by the user, but perception is reality)
  13. Meet to talk about what is “wrong”
  14. Fix “bugs”
  15. Re-deploy
  16. Repeat steps 7 through 16 forever (because nothing is ever done)

Yes, of course there were defects in my software after it was released but not many; nobody is perfect. However, the majority of issues I got from end-users were because they asked for one thing, got it, and then discovered that they wanted it to work another way. If there was more planning then issues like these would creep up less. I always develop to the spirit of the requirements (in this case my notes are my requirements).

A Perfect World

Projects should go like this (off the top of my head. I’m not adhering to scrum or waterfall here):

  1. Project initiated somehow. It could be over email. “Hey, Steven, project ‘Make a Cool LOB Application’ is going to kick off. Let’s meet on <some date here> at <some time here> to talk about it.”
  2. Kick off meeting with all the stakeholders. This would be an opportunity for the dev team to meet with the end-users (or client) and discuss the project at a high level.
  3. Several meetings to gather requirements from the users. This requires time and probably many revisions. Requirements would be gathered through steps 4 through 7.
  4. Perhaps monitor their normal routine if the project is going to replace or enhance something they already do
  5. Meet to discuss how the application should look and feel. This should be several meetings.
  6. Develop a prototype, or mockup, to show to the client
  7. Once the mockup is approved by the client, begin designing the backend
  8. Design the database backend
  9. Architect the solution
  10. Develop the solution to the spirit of the requirements
  11. Release to QA every so often (maybe part of the sprints if you’re doing scrum, or after an iteration) for testing
  12. Fix reported defects and work on the next iteration
  13. Release incremental builds to the client for quick feedback
  14. Continue until the project is complete
  15. Release to production and move on to something completely different

Something like that. The point is, there has to be some form of structure to a project for it to have a chance to succeed. Also, one person cannot be everything on a project.

Software development is not just as simple as typing. It is an engineering discipline and must be respected and treated as such.

A Man of Many Hats

wearing-many-hats

I have to wear all of the hats because, well, I’m the only one on the project:

  • Designer
  • QA
  • Developer
  • Business Analyst
  • DBA

I’m not the least bit interested in being a web designer, though Bootstrap is kind of cool. I love QA and software development. I am not that interested in being a Business Analyst or a DBA.

Typically, the projects I do are no small task and are expected to be completed in an unreasonable amount of time.

All of this ranting is just to say that if companies instituted a proven process (like scrum), put more resources on projects (instead of expecting a single person to do it all), developers wouldn’t be as stressed out and projects would be of higher quality.

It is not just typing.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s