Wednesday, August 14, 2013

Survival of the Fastest: Software Development

Today instead of talking about code and my previous projects I would like to talk about something really important for all of us coders/programmers and any one even remotely associated with it. Today's topic for sermon is "Speedy Software Development".

I know that the best of you, readers (which I hope is most of you readers), know about Agile Software Development Methodology. (Don't sweat! If you don't know, then look up the "Further Reading" resources links at the bottom of this post). It's an innovative way of developing software in the fastest means possible. But, what if I say some (additional) simple techniques could yield a faster method? Some of you might be aware of the techniques and tricks I'll be discussing today and none of what I'm writing here is novel.

So, let's cut to the chase;

Open-Source

You are not alone (in your problems). Someone somewhere sometime has already tackled with your requirements and problems. All you have to do is embrace his legacy and yes, credit him for his contribution. Most of all the major problems we face has been presented in an optimized and professional open source package. Companies and programmers, alike, must learn to leverage it for rapid software development. You don't want to reinvent the wheel. Do you?

For the n00b:

A lot of new programmers and students overlook this useful resource and later, over the years, they gain the wisdom of using Open Source Technology. So, it's my best advice to anybody new to the coding community to immerse himself or herself into Open Source Projects. I'm not saying you need to contribute to it. I'm saying to learn and use it in whatever project you want to do. Reading and studying Open-Source code will also make you a better programmer. You'll often stumble into some new repository or API which will showcase you great new features which you had never dreamed/thought of before or previously considered impossible owing to your naivety in the subject.

For the PRO:

For the professional it is of utmost importance to keep up with the latest developments in his/her field of expertise. Open Source software and APIs can also use some polished distilled wisdom for upgrades and new features which seasoned professionals are replete with. This will also help team leaders, software architects and researchers to decide, plan as well as utilize the cutting edge of current times for the best delivered projects and solutions.

For the Company!!

Now, comes the important part. Companies worldwide can help in the Open Source Initiative by kind or cash. They can help by allowing employees to work on certain OS projects when they're free or assign employees (without any current tasks/projects) tasks to either contribute or use OS to build new products for the company or even the world at large.

Also, when companies devote teams and departments to Open Source Initiatives they can seek funding and donations from other companies for such projects and gain a small share of profits over it or at least balance the overhead expenses to make it a non-profit. Giving burned out or overworked/pressed employees the option to switch to a deadline free OS projects will recuperate their coding spirit and mind, while staying on the payroll and not costing much capital for the company (considering its funded enough with OS donations).

Automation, Code Generation and Company Project Repository

Ever found your task to be repetitive and boring? Does you work feel like it should be done by a robot? Well, then build one (or use one)! What I'm most surprised at is that even experienced programmers and experts get into this kind of menial chores. They either copy previous source code or unintentionally repeat large chunks of project components already developed earlier by someone else in the same company for some other client.

The Archive

 In the era of paper dominant office days and even now, a lot of offices kept archives of projects and documents for future reference. This is most useful to tackle repetitive tasks like building a web-service, a database driven desktop application etc. Over the days, months and years an organization will continue to accumulate a lot of achievements and accomplished projects under it's belt. This when well preserved and circulated among the coders as a library of information/samples will be a boon for rapid software development. 

Question: What is common between an application which maintains pharmacy inventory and a grocery inventory application? 

Ans: A lot! There is a lot of similarity in database schema, application logic and even business usage. Then why don't we just re-purpose the previous grocery store app to handle our new pharmaceutical demands? This will save you a lot of time to work on the core features of this new pharmacy inventory system. You may want to add a small feature that will notify alternative drugs or harmful drug combinations which may have been prescribed incorrectly by the doctor.

Thus, every IT or software development company must keep a unified distributed project repository which can be accessed by an employee in any of it's branches worldwide with a click of a button. Think of it? How simple will our tasks be? But then there are certain challenges to this approach:
  1. Bad Code (style, approach, architecture, performance etc). Almost any product that can run is shipped out the door to customers or clients. It may happen to have some small nifty hack or jury rigging and duct tape under the hood to keep it working. Such a product is volatile and may break upon alteration or up-gradation.

    Fix: A set of informal personal log should be provided to programmers/employees working on the project to document their contributions, potential problems, hacks applied and jury-rigging done with the project while they are still working on it. This log should be kept together with source code and documentation for better reference in the future.
  2. Obsolete Code primarily designed in archaic languages for ancient systems may clog up the archives with no further re-usability.

    Fix: Such projects should be carefully weeded out into another obsolete or dead code "cemetery repository". This may also require a special archivist with the dedicated duty of studying code, maintaining the archives and guiding other programmers with useful information.The archivist can be anybody from rookies to experts or even dedicated professional (will probably require a team due to the varying age of archived projects and diverse languages applied to it).

    Archived projects can also be made to reorganize themselves by timed automation.(For example a Project developed in a new popular language may be timed for a decade or two while perennial projects in C, Java etc can be set for five decades or so which may be extended upon inquiry from the archivist. I hope you too believe that the JVM will not be obsolete anytime soon nor will C.) Such obsolete projects may even be distributed as open source for education and experimentation purposes.
  3. Dirty Code is source code which is well, dirty. You know what I mean. The same old, lack of comments when needed, incorrect design, ambiguous functions and suspicious noise code (Don't know what that small method does? Not there in the documentation? Not mentioned in the programmer logs? Could be a logic bomb? Or, am I being paranoid?). Dirty code is unsafe to work with and providing global access to source code for any of your programmer anywhere on the planet with sufficient internet bandwidth can cause such dirt to accumulate.

    Fix:     A proper access logging mechanism is required to observe who accessed the archives, when was the archive accessed, what was accessed in it and what was done with it? Also, a rule of forking existing repositories must be enforced to preserve original source code (which can be easily handled by any version control system worth its salt). Also, new recruits can be assigned to study and observe for such anomalies while cleaning such legacy systems.
  4. Cheat Code? Yes a repository or source code that is stolen from your archives under corporate espionage.
    Fix: Already discussed measures of access logging and version control systems which handle such problems.

 Wisdom of Wizards and Templates

The repetitive work can be easily identified with the help of a proper archiving system and such projects and problems should be streamlined with the help of incorporating Wizards and creating Templates or Stub generating programs. Also known as Code Generators. Such tools can accelerate software development exponentially. Want to build a social networking site every time? This might be your tool. But, careful thought should be made before applying such automation, as design flaws or hard coded errors could creep into new projects and will be difficult to track. Again, one must strive to abstract the mind work from the menial chore carefully. Custom requirements may require you to hand craft such solutions, sometimes, even from scratch. Don't be tempted to use this as a silver bullet.

Code Generators can also be scripts to code all the lines of the project as per observed design or pattern. Such, custom tools are generally one-off and built by the best programmers (who will also be of the laziest programmers - quoting Bill Gates).

Extended Archives

Companies can extend their archives to other companies as read-only or reusable resources. This can be done by levying some pay per view or annual rental/subscription charges. As the archive is categorized and with proper access rights and restrictions in place, will hopefully keep sensitive projects off limits. This can also help colleges and universities in exposing students to existing industrial endeavors.

Colleges can too build such repositories for student and teacher projects, examples, notes, resources etc. This can help in learning rapidly from existing source code and extending them further with new features.

Colleges may even extend such archives with collaborating with other colleges and industries. (Hey, you may even want to shift to GitHub.But, if certain features have to be specialized for students then good go build such repositories and archives.)

[Unfortunately in India almost every school and college dumps their students assignments and projects without a moments thought. While some teachers do retain some good projects but, is that enough?]

Points of Importance

Some points to keep in mind are;
  • Software should be developed like component assembly, where each set of features is provided by a certain package or component of code which can be either purchased (in case of Licensed), copied (in case of Open Source) or custom built. This makes extension, maintenance and reuse very efficient.
  • Programmer should learn and use clean coding style and follow proper coding conventions in order to keep their code legible and useful for others.
  • Style and standards can be enforced by companies to keep it easy for projects to be legible to other programmers outside the original developer team.
  • We should pause to think about our work. If its iterative without any requirement of creativity or customization then a proper approach should be taken to automate or simplify the task.
  • We should read more and research more while in the planing and design phase in order to optimize our approach and speed up the actual software coding process.
  • You may thank me for this blog post. I'll be super happy. ; ) If you have any other cool tips add them in the comments.

Resources for Further Reading:

Agile Software Development Methodology 

Must read books and inspiration (as well as resource) for this blog post
  •  The Developer's Code: What Real Programmers Do. By Ka Wai Cheung.
  • New Programmer’s Survival Manual. Navigate Your Workplace, Cube Farm, or Start up. By Josh Carter?

Project Souce Code sharing repositories and other version control systems

Posted by at
Labels: , , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)