The Software Engineer

Martin, Robert C. (2011).  The Clean Coder: A Code of Conduct for Professional Programmers . Old Tappan, NJ: Pearson Education Inc. https://sites.google.com/site/unclebobconsultingllc/books http://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073/ Introduction  The book, "The Clean Coder", focuses on aspects of the working life of a programmer in the software industry. Robert C. Martin ("Uncle Bob"), through this book emphasizes on the various aspects in which a programmer can be and appear "professional". He explores, through his long experience as a programmer, the behavior of software developers and how they are perceived by other professionals in the industry. This book can be described as a manual for the coming-of-age of a software development professional from a scruffy hacker who would be non-committal and tardy to a clean coder who asserts professionalism through her behavior and work. I have personally had an e

Sutherland, Jeff, & Sutherland, J. J. (2014).  Scrum: The Art of Doing Twice the Work in Half the Time . New York, NY: Crown Publishing Group. https://www.scruminc.com/new-scrum-the-book/ Introduction  The author, Jeff Sutherland, along with Ken Schwaber conceived Scrum as a method of improving productivity in software development teams in the early 90s. Coming from the horse's mouth, one gets an insight into the history behind Scrum and how the author evolved the process with every project he worked on or consulted for. One also gets to view the process through Sutherland's eyes as he applies that to every project. He provides ample anecdotes to supplement his arguments towards using Scrum as the process of choice not just in software development but also in other engineering as well as non-engineering domains. That said, it also brings about a bit of a confirmation bias of Sutherland regarding the efficacy of Scrum. Through the reading of the book, one desires

Long since I have updated here, I went through a number of experiences to land up in developing within the Android platform. Being pushed out of my comfort zone of server-side and database development, it is a fresh adventure by itself in developing mobile applications. Away from my usual rants about software engineering, I would like to be a bit more specific about a topic. Software architecture can be defined in a number of ways. The software engineering institute has compiled the modern as well as the classical definitions of software architecture. http://www.sei.cmu.edu/architecture/start/glossary/moderndefs.cfm http://www.sei.cmu.edu/architecture/start/glossary/classicdefs.cfm To be concise, software architecture is a set of models which define the highest level of system abstraction. This may begin with understanding the qualities of the required system and the tactics that enable those qualities. The summed up architecture document will consist of static views such

I would like to make it clear that my intentions are to advocate software engineering through this blog. Having worked for about 3 years under the title of 'Software Engineer', I realized that it is a little more than just programming. However what I did was mostly programming. On the other hand, I have been working since 5 months using the title "Web Programmer" while most of what I was doing should be considered software engineering. I have been involved in planning, requirements elicitation, process engineering, architecture, data migration, database design, user interface design, and also programming (in a language I had very little prior experience in: remember learnability!). I smirk at the irony. Around the world, over the years... It has been over two months since my last update. Yeah, I know that I say that every time I post something new. This time, I decided that I would rest it out and see what other bloggers have to say about software engineeri

Adapt or perish, now as ever, is nature's inexorable imperative. -H G Wells I have been away for a while: had a lot of coursework to complete and I am finally out of it unscathed. Hi everyone, welcome back. As usual, I will begin my rants with the disconnect between the job market and the definition of a software engineer. Recently, I received a call from a company (which I do not recall applying to) asking me "In which technology are you a software engineer?" It is the same as asking an automobile engineer, "In which type of vehicle engine are you an automobile engineer?" Specialization, you say? Not really. Although automobile engines do not evolve as fast as programming languages, an engineer must be ready for all. (S)he is the one who should make the decision regarding which is most suitable. It basically undermines the factor of learnability within the engineer. Is it not possible that an engineer learn about a new technology and imp

I started writing this blog in order to explain what software engineering is. I have noticed that most people use the words "software engineer" to describe a person who is basically a programmer. Unfortunately, that is a misguided definition of software engineer. I have attempted to clear that fog in my previous post. However, no matter what definition is used, what is it that we really need? A software engineer or a programmer? This post, however, will take a tangent into one aspect of Software Engineering: Requirements Engineering. You can learn more about requirements engineering here - http://en.wikipedia.org/wiki/Requirements_engineering Requirements can be divided into two broad categories: functional and non-functional. Functional requirements are those details which form the basis of the software being built. This consists of the main reasons why the particular product is being developed. As an example, one of the functional requirements of the Amazon Kindle read