Best Practises for Web Development

 

The following are a few questions we have been asked about web development and our approach to building software.

 

1)            Website development to provide our secure access to their accounts online

 

-          I would envisage a modern cleanly designed website in semantic HTML that would either be:

        --responsive design (auto adapts to the resolution based on the screen size

        --sufficiently well-formed, semantically correct and generally valid html that it would work on all devices.

 

-          Images for the website should be optimised. http://www.smushit.com/ysmush.it/ is a good resource. Also where there are many smaller images consider using Sprites.  Images should be served at their original image size where possible. Otherwise you should use something such as Photoshop to resize your image, this will result in the saving of bytes

 

-          CSS styles should be in external files and in the head part of the document.

 

-          Ideally no inline JavaScript should be present in the HTML and any script should also be in an external file. This “.js” file should be referenced at the end of the HTML. By placing

JavaScript files at the bottom of your documents, you’ll ensure that JS files will be loaded only when the content has been properly displayed.

 

-          Consider security, encrypted passwords in the database and use of SSL (https).

 

-          Make sure there are no 404 bad links or bad requests for missing images or resources. Although these requests don’t cause any data to be downloaded, it is still a wasteful resource as the browser has to initiate the request in the first place.

 

-          Consider performance: One of the most important aspects of improving a web page’s performance is minimising the number of round trips that the browser needs to make to the server. Every file that your website includes (such as CSS, JavaScript or images) all need to be downloaded to the browser. By minimizing these requests you will speed up the page significantly. If you include separate CSS files for different parts of your site then you will find it beneficial to include all the CSS in one style sheet, likewise for JavaScript or other resources. Also Minifying HTML, CSS & JavaScript, CDN’s and caching can save bandwidth.

 

 

2) Website development to provide access to status updates of items

 

Sounds like a dashboard design perhaps something like Google do to describe the status of their services

http://www.google.com/appsstatus#hl=en&v=status&ts=1363969348428

 

 

3) We have 4 disparate systems for our different companies. In each of these there is a table that we wish to be centrally maintained for all systems?

 

Assuming it’s a database table here are a few options

- Sync Framework looks good and has good support in SQL Server 2008- http://msdn.microsoft.com/en-us/sync/default.aspx

- SQL Server Merge Replication - http://msdn.microsoft.com/en-us/library/ms151198.aspx

- Open the SQL server port 1433 so that any application can connect to it. (Perhaps authenticate by IP and use a restricted user when connecting that has access to only the one table)

- Build a web service in front of the table that is exposed to the internet and that all 4 systems can use.

 

4) A new diary system to alert to recurring and / or one off tasks

 

A diary system is something that a lot of people have already built and that a lot of people require. It maybe that a component exits that meets 80% of the requirements for development cost of 20% of the normal effort.

http://www.componentone.com for example have tool-kits for scheduling. Their slogan is “.NET Tools for the Smart Developer: “ There are also free Jquery plugins with full source code like http://arshaw.com/fullcalendar/ that can be used as a starting point and that I have used in the past.

 

If an "off the shelf" component doesn't fit and a bespoke piece of software has to be built then for ideas and inspiration on possible features we should look to existing Diary systems. A lot of the bigger companies and software packages ( Apple, Google, Microsoft windows 8 ) could be explored to build the requirements.

 

 

 

 

Front end Developer and JavaScript expert?

 

Frontend Developer and JavaScript expert?

If you are a JavaScript (HTML5, CSS3, Jquery) developer who is always exploring specific techniques, strategies and solutions in order to develop robust, cross browser JavaScript code then we really need to hear from you.

 

US

We are looking for a frontend developer (ideally senior) with extensive JavaScript experience to work with a new and exciting game changing Start-up. Launching later his year with significant television and media exposure this is the chance to get in at the start of something that will be big.

This is an excellent opportunity to join a company where there is excellent scope for growth and career progression. In addition this is an exciting and challenging project with a talented and diverse team where there is never a dull moment.

 

You

You know a number of JavaScript libraries

You also stay up to date with new JavaScript developments

You understand those JavaScript libraries

You can build your own JavaScript library from scratch

Oh and we need HTML5 & CSS3 but of course this comes naturally ;)

As a frontend developer you will be building and implementing high quality user interfaces.  Ideally you can review and influence on-going client-side design, architecture, standards and methods.

 

Desired Skills & Experience

Understanding of JavaScript libraries and ability to write your own JavaScript code

Skills to deliver robust, cross browser JavaScript code

Hand coding XHTML

HTML5, CSS3

Mobile HTML

Javascript expert. Jquery, Prototype, Dojo or similar

AJAX and JSON,

Photoshop

 

Beneficial

Asp.net C sharp

Agile (or similar) development methodologies

SVN

Knowledge of UI design, including accessibility and usability

Ideally some knowledge of back-end technologies, particularly ASP.net

 

Apart from the technical skills detailed we require:

Detail orientated people

Extremely Passionate

Problem Solver

Push to improve every project

 

Remote/ Flexible working and working from Home is available for the best and brightest candidates. However candidates must be available to travel to the Birmingham area periodically. There is a competitive salary and package on offer for the right candidate so apply now to find out more.

 

 

Practical Remote Development Team Management with Agile and the No silver Bullet approach

 

General approach:

I subscribe to the “No Silver Bullet” opinion on software development.

http://en.wikipedia.org/wiki/No_Silver_Bullet

“At the heart of the argument is the distinction between accidental complexity and essential complexity. Accidental complexity relates to problems that we create on our own and which can be fixed; for example, the details of writing and optimizing assembly code or the delays caused by batch processing. Essential complexity is caused by the problem to be solved, and nothing can remove it; if users want a program to do 30 different things, then those 30 things are essential and the program must do those 30 different things.”

Everyone wants to find a silver bullet (not just in programming, but, for example important today, in things like banking) that makes everything a breeze. It's human nature to believe in these things. Assuming that some magic elixir will be found to make simple solutions for those complex problems is often to ignore the many small improvements that do help. In essence what I propose is a simple and pragmatic Agile approach.

In simple terms Agile software development is the "just makes sense" way to go about programming, doing small bits of work in small teams then running the code quickly to detect problems, then repeating the process again.

The Agile manifest itself can be viewed here -http://agilemanifesto.org/

Up until maybe four years ago, I had a one-dimensional view of "Agile" programming, namely that it was an idiotic marketing scam, a sort of technological virus implanting itself in naive programmers, the kinds of programmers who buy extended warranties and self-help books and who believe doodling on cardboard index cards will suddenly make software development easier.

Since then I've worked on a few projects that used a remote Agile development strategy, with varying results.

The most successful Agile projects I've worked on remotely involved the following.

·        Daily VOIP morning scrum style meetings.

·        Clear iteration plans

·        Automation tools such as continuous integration / build servers.

·        Diligent use of project tracking tools

 

Working in a virtual workplace.

A “virtual workforce" can turn out to be beneficial as everyone is on the same level. These individuals are either lonely and isolated, or pretty happy with their arrangement. We can influence the outcome towards the latter by setting up frequent communication and transparency.

In Agile working, the need for frequent communication is a key ingredient. Routine is also important - regular scrums (meetings) at the same time of day really can help the communication flow.

I know what I personally get out of “working virtually”. I have the quietest, best equipped office of my career.  I've got all the tools and reference resources in one place.  I control the environment.  I have flexibility to work when I'm most productive - and do things that improve my quality of life.  I feel this helps me deliver higher quality work than if I were in a cube farm.  

In my experience the problems of remote work are often due to lack of communication, both 'face-to-face' and lack of or poor use of project tracking tools. In general it can be harder to communicate with remote workers. If the remote people have strong "remote" communication skills this is probably a non-non-issue.  On the upside if we get the process running correctly we can hire the best of the best when we don't have a geographical location restriction.

For example we can hire the best JavaScript developer that lives near the beach and won't move to the midlands (of course certain conditions need to be met first but it's an option that we might not have otherwise.)

 

How do we become Agile?

There are many ways to become Agile. Purists say that you are not really Agile until you do everything in a truly Agile fashion. That might be true but trying to start everything at the same time could be a recipe for disaster.

To make the transition to Agile go smoothly, I believe we should focus on a five principles:

1)     Perform daily stand-up-meetings.

2)     Use of correct Agile and online collaboration tools

3)     Encourage open communication and discussions throughout the entire day.

4)     Break stuff down into small manageable chunks and use continuous integration.

5)     Develop and strive for clean, well-shaped source code

 

1. Daily stand-up-meetings or Scrums

Daily stand-up-meetings are as simple as they sound. You gather the team on Skype and everyone takes turns in answering three simple questions:

 

 

-       What did I work on yesterday?

-       What will I work on today?

-       Is there is anything that is blocking me?

 

 

Each person gets one minute on average (sometimes more, sometimes less), and overall it shouldn’t take more than 10 minutes. That’s it

How does it help?

It helps the team avoid duplication: If Doreen plans to work on a problem that was already solved two months ago by Amir, then you can bet that Amir (or someone else) will tell Doreen before she even starts wasting time.

Clear roadblocks: If someone is blocked by something particular, this is the perfect time to check who could help: “I have been working on bug X, with little progress. Has anyone seen X happening? Let’s chat after the stand-up meeting”.


Detect roadblocks: If John tells the same story for the fifth time in a row, everyone else will realise that he is severely stuck and needs a hand. Catch him right after the meeting and get him some help.


Boost team coherence and commitment: Team coherence and commitment is increased when everyone speaks to everyone else on a regular basis. Especially when you don’t all work in the same room, or when different members of the team work on different aspects of the same project.


Increase project manager accountability: Daily stand-up-meetings even make the project manager more accountable. When your manager comes to ask your status, would you dare ask him his? Probably not. But in a daily stand-up-meeting the manager is reporting his status to everyone else.


Increase team member accountability: Daily stand-up-meetings make each team member more accountable as well. A manager might not notice that David is over-engineering his solution just for the fun of it – but the rest of the team will.


Spread transparency:  To the project manager, the project is probably transparent already. But there is immense value in team-wide transparency too. People are not machines, and love knowing what’s happening.

What are the costs and risks?
Admittedly, the daily stand-up-meeting does take time. And some people don’t like speaking in front of others. And at times the meeting can distract people from doing important work. These are all valid points. But we need to compare them to the costs that arise by not having this meeting.

How much work would be lost by double work, or by people not realising they are stuck? How important is staff retention to us – and what better ways of open communication can you get at a price tag this small?

As long as we apply common sense and accept that some people occasionally may miss a meeting, and that others may not be great at speaking (but do attend and listen), there is little to worry about.

A bigger risk is people who like to hear themselves talking. The stand-up meeting is not for story-telling. We need to be strict about the time-limit. Someone needs to have the guts and speak up – in a friendly way, and depending on the individual it may make sense to do this after the meeting, to come across less confronting.

The same applies to discussions. Stand-up meetings are not for discussions. They should encourage discussions, but after the stand-up-meeting, and with just the people who really care. If someone frequently starts discussing what someone else said we take them aside and explain that the discussion is great, but it needs to happen after the meeting.

It will help to nominate one person to become the ‘Stand-up-Champion’ who will make sure that the meeting remains focused and finishes quickly and on-time. This person also makes sure the meeting happens in the first place, so the person should not be too shy to shout and get the meeting started. This role should probably be shared on a round robin basis.

 

2. Agile and online collaboration tools

One of the central values in Agile is "Individuals and Interactions over Processes and Tools". A great team is without doubt the fundamental key to success on remote (and frankly any) projects. However in at a close second are the tools used to facilitate the project management and development.

Good tools I'd recommend are

http://www.pivotaltracker.com/

http://campfirenow.com/

www.skype.com


3. Encourage open communication

Besides the daily scrum, we should encourage open communication and discussions throughout the entire day. This can often generate new ideas or find a solution to a bug. After all, open communication is the cornerstone of a successful project-speaking on the tasks they did yesterday, the tasks for today, and the problems they have encountered.

 

I would advocate a Skype room (easy to chat and hop in out of voice) that the whole team is in all day. This could serve also as a coffee talk" mechanism to replace the sort of chat that is often found around a water cooler or in a smoking room.

 

4. Break stuff down

Working in remote teams does come with an increased chance of misunderstandings. But by breaking the project down into smaller iterations, misunderstandings and problems can be detected much earlier. With clarification of requirements and immediate code fixing, the project can move forward in a timely manner.

 

“Continuous Integration is a software development practice where members of a team integrate their work frequently; usually each person integrates at least daily — leading to multiple integrations per day. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.”

 

Using this practise lets people take a look at what’s been built, and if it functions correctly give it to the testing or management team

 

5. Clean and Crisp Code

Clean, well-shaped source code can prevent headaches down the project road. Part of the Agile framework includes constant updating and revising of existing code. Ensuring the code is clean, crisp, and commented can minimise the response time tremendously for requirement changes.

At the end of all Agile software development projects, the code has to be handed off to the support team in some manner. Well prepared documentation will make this knowledge transfer easy and cost effective as at some point, the end user will be calling for help and reporting bugs or feature changes.

 

Other factors

Other non-trivial matters that I feel need to be addressed in considering an approach is:

1)      How do we test, do we have a testing team?

2)      Who is the project manager?

3)      Who has responsibility for the IT budget?

4)      Who has responsibility for the overall technical strategy?

5)      Who is the technical team leader?

6)      How much access have the developers or development manager to the business and business requirement analysts?

7)      How and who reviews code and does technical quality assessment... Is it one individual or is it peer to peer type reviews?

8)      Do we have a roadmap for future releases post go live?

9)      How secure is our current source code?

10)   Is our software logging enough data to help support staff post go live and fulfil any future data reporting requirements we might have?

11)   Have we got an adequate back office system or plans to build one that will allow the support team to assist the customer’s queries when the software goes live?

12)   Architecture of the servers and server hardware that the software sits on: Have we selected a server vendor? Do we have a backup/ redundancy and disaster recovery plan?

13)   Performance and security considerations... Do we get outside help and independent auditing and certification that our software is robust and secure?

14)   Daily builds of the software to the staging area how best to do this and who is responsible?

15)   Do we use In-house SMS and email services or do we outsource... How do we test the reliability of these services?

16)   How often to get everyone together face to face?

17)   Have we got the right people in the team?

18)   Where are we NOW and how soon can we go live?

 

Conclusion 

What I have outlined is a fairly high level view, but it does illustrate what I feel are the five key practical cornerstones of any approach I would advocate.

How these are implemented in practise is dependent on the health of the project, the state of the current code and the deadlines enforced by the business.

People are often hesitant about change, especially if they have been subjected to frequent random change before that didn’t help. As with every change, I think we should first make the proposal, discuss it with the team and take on their feedback before we actually get started. I feel it’s important that everyone buys into the concepts. In addition the actual practical implementation of these should and must be driven by the people that will actually have to use the process.

I've always thought the biggest silver bullets in any project are the qualities of the people working on the team (not just programmers, everyone involved is important). Smart, experienced people who work by consensus or at least in a trusting hierarchy, able to pick the right tools and technologies for the job, and given the right level of support by management, QA, product and everyone else who contributes to the end result.

When I've worked in places or on teams which were mismatched, poorly lead, used tools incompatible with the team members, had overly complex methodologies, the result was uniformly bad.

There is “No Silver Bullet”. A great motivated team communicating effectively and efficiently is without doubt the fundamental key to success.

 

Happy New Year( 2013) From TheIthelper


Happy New year !

 
Well time does fly and after nearly 2 years of working 80 hours a week with multiple plates spinning, we finally got a chance to update our blog and indeed our Portfolio section. You can view our recent projects here:
 
Our new years resolution is to continue to keep this blog and site up to date and actually blog about cool interesting technological developments both in our world and in the world in general.
 
Have a great year