Archive for May 2013
Pair programming is one of XP practices. This practice embodies an extreme (hyperbolical) idea of code review. If the review practice allows improving the code quality, it’s easier to perform it constantly during refactoring and writing a new code.
The problem of a regular code review concludes in the superficial programmers’ feedback when they view your code. But as soon as developers start working with the code, they start providing the real feedback with all the flaws and weaknesses.
How to do that?
While pair programming two people sit together, side by side at one computer. One of them is a leader, he holds the keyboard and the mouse. The other one performs a constant code review of the first one to determine the tactic and strategic drawbacks in the code, including mistakes in the program syntax, logics, misprints and realizations that do not fit the current design of the system. After a certain time the programmers change their roles or the pairs themselves.
One of the most common reasons for doubts about PP among managers and programmers is: won’t the development become slower if two programmers work on one task?
The research show that in pair work is done either with the same speed as if the programmers worked alone, or a bit slower (15%). At the same time the code is much more qualitative and contains fewer mistakes (60%) in it.
• As a rule, code review (as a separate procedure) is not necessary any more.
• Even the most experienced developer can not know everything. The presence of 2 developers allows solving the tasks quicker and more effective.
• The number of mistakes decreases. Besides, the mistakes themselves can be detected in the course of work.
• Developers concentrate on work better and get distracted less. This point can be considered as a minus as well. Breaks are still necessary, that’s why pair programming requires 10-20 minutes pauses every 40-60 minutes.
• Developers know most part of the code. Thus, if needed they’ll be able to make modifications more effectively.
• In case there is required a two code parts confluence, PP is a quicker and more effective way, than if one developer wrote the code and afterwrds sent it to his colleague giving the explanations on the way.
• Programmers learn to solve the problems, discuss the issues and find the compromise collectively.
• Not everybody wants to work in pair. For somebody it’s psychologically uncomfortable, somebody can be not satisfied with the partner. Besides, the code of every developer is unique to some extent.
• Most of the managers will think that it’s not profitable to put two people for performing one task at one working place. The costs of development may increase, although it’s compensated with one significant advantage – improvement of internal architecture and fewer mistakes in the code. In 1999 there was held a research on time expenditures. According to the experiment, the time spent has increased by 15%, nevertheless, the quantity of the mistakes in the code has decreased by the same 15%. Also, it’s worth remembering that editing mistakes at the development stage saves a huge amount of time at the supporting stage.
• It’s necessary to coordinate the developers’ timetable.
• Human factor. For pair programming one needs to have patience and a desire to work in pair. If one of the participants just sit and watch, or start dominating without listening to his colleague’s opinion, such kind of development will not lead to any satisfaction or a higher performance.
1. Sharing of experience: It often happens that working in pair you learn about some new short keys, interesting tools for speeding the work. Anyway, you constantly learn something new watching the others programming.
2. Knowledge about the system: Regular change of pairs contributes to knowledge transfer about different system parts inside the team. It makes for tracking the process of system development better, improving the system design, not duplicating the logics
3. Collective code ownership: When everybody participates in writing all parts of the system, the personal class or build ownership is out of question.
4. Tutorship: As the practice shows, the easiest way to integrate into the project happens in the process of pair programming.
5. More communication: Communication inside the team helps building relationship based on trust. Standups and retrospectives certainly bring in some communication to the routine work, but it can not be compared with pair programming.
6. Coding standards: Sitting in pair, constantly passing on the keyboard and changing the pairs, programmers transfer their knowledge about coding standards applied on the project. You will not have to apply automatic tools for checking the code quality.
7. Improving the discipline: Working in pair one wants to show his interest and level of experience to the partner. So, shifting to the social networks to look through the latest funny pics would be problematic.
8. Fewer interruptions: While working in pair you will be less distracted by side factors. As the time of 2 people is more valuable, their work becomes twice more expensive.
Pair programming can be much more interesting and enjoying than solo programming, if it’s done in the right way. And vice versa, it can become terribly boring, if there was chosen a wrong approach.
According to my observations, it’s rare that people do pair programming in the right way. Most attempts of pair programming are ruined with one of the following anti-patterns:
1. Watch the Master: Such situation happens if in pair we have a programmer who thinks (or even he really is) himself to be a guru in his area. The questions of a less experienced developer about the code that is generated by Master, are mostly ignored. There is also possible an option when he is constantly said to google it. The Master doesn’t hurry to pass the keyboard to the partner. When the keyboard is finally at his partner, the Master loses the whole interest to the process.
2. Dictator: One of the developers in pair always takes a tough and ultimate position regarding all the decisions that are connected with the current tasks. In such situation, mutual assistance or learning in pair is out of question.
3. “Bring us some coffee”: Pair sits down at the computer. One of the developers takes the keyboard and starts writing the code, saying to his partner: “While I’m writing the code, go and bring us some coffee”. It breaks the basic idea of a mutual involvement into work.
4. Silent partners: The partners do not communicate with each other, do not comment their actions and decisions in the course of work. With the absence of the feedback the core idea of pair programming is lost.
5. Distributing the tasks sitting at one table: Programmers sit in pair, take two computers at one table (f.ex. PC and notebook) and start working in parallel.
6. Uncomfortable place of work: The most frequent reason for being tired while working in pair is an uncomfortable position of the keyboard and the monitor for the “leader” at the moment. When the keyboard is passed from one developer to another, the one who got it doesn’t shift to the center of the table but leans to the keyboard thus creating some difficulties for his proper work.
7. The partner is occupied with his own business: During the work one of the partners moves away from the working place, checks e-mails etc.
8. Specific environment settings: Every time the leadership shifts from one partner to another, each of them starts reconfiguring the environment: tabs, fonts etc.
9. Own style: Each of the partners sticks to his own coding standards which leads to heated discussions and a terribly formatted code.
If you see the programmers work according to such anti-patterns, provide them with the feedback pointing out their mistake. The practice shows that simply a bystander can align the pair work.
In the end I’d like to say that I vote for pair programming in marathons, long-term projects, fully understanding that it becomes unbearable while working on short tasks.
Pair programming should be perceived as a tool, not a cure-all for all the problems. Such practice is really worth trying to understand where it will be useful and when you can manage without it.
Have you ever had such practice of PP? Please, share your impressions and thoughts on this point. It would be really interesting to learn your opinion.
Business Development Manager
Professional Software Development
For some years, Agile methodologies have been widely adopted within the information technology software world to bring new products and services to market quickly and efficiently, increasingly taking over from more traditional approaches such as ‘waterfall’. While it may have promised much, Agile has not been without its critics, who say that it does not live up to expectations, that users can become too bogged down in the processes and lose sight of the end goal. They also fear Agile projects become siloed into teams, rather than being visible to the organisation as a whole.
However, as an increasing number of companies are finding, Agile CAN deliver on expectations, if some simple principles are followed: what might be called “pragmatic agile”. Supporting tools also have a role, such as SCM (software configuration management). SCM can help ensure that a project remains visible to all the key stakeholders, while supporting Agile-related tactics such as Scrum.
So exactly what is Agile? First introduced in the late 90s, Agile methods are well established in the software development world as tools to accelerate time-to-market. They aim to emphasise the items on the left below, while still appreciating the value of the items on the right:
– Individuals and interaction – over processes and tools
– Working software (or product) – over comprehensive documentation
– Customer collaboration – over contract negotiation
– Responding to change – over following a plan
Taking these elements individually, let’s look at what they mean in practice.
Individuals and interactions – over processes and tools
This does not mean that there is not a place for processes and tools – of course, there has to be – but Agile is very much about people communicating with each other, ideally verbally and not just via email. A common communications element of Agile methods are daily meetings, or “stand-ups,” to review the current status of a project and to iron out issues before they escalate. In Scrum processes (see later), planning meetings provide an environment in which to understand requirements of the backlog and how to address them with collective support on the effort required. This approach helps to engender more creative thinking, because people have an environment within which they can safely suggest ideas.
So given this environment, how might tools provide support? As an example, a strong SCM system is invaluable in two ways. First, it provides visibility into how all the work fits together to deliver a working product. Second, it allows features to be developed in parallel across Scrum teams, or to move changes between sprints if work has not been completed as expected.
Working software (or product) – over comprehensive documentation
Whatever the project – whether in mainstream IT, games development or embedded software design – all too often, projects can become unwieldy, with the temptation to ‘over engineer’ and lose sight of the original goal and deadlines. Agile encourages teams to maintain focus on the outcome. This can mean delivering a working version of the software that may not have 100 percent of the features originally planned, but the product still has usable functionality. A central tenet of Agile is to take an iterative approach: it is more effective to deliver a product early and then continue to improve, rather than delay time to market.
One common Agile method is Scrum. Scrum is an iterative and incremental Agile software development framework for managing software projects and product or application development. Here’s a quick overview of the Scrum framework from the Scrum Alliance:
A Product Owner creates a prioritised wish list called a product backlog. The Product Owner is a proxy for the customer when determining features and priorities.
During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
The team has a certain amount of time, a sprint, to complete its work – usually two to four weeks – but meets each day to assess its progress (daily scrum).
Along the way, the Scrum Master keeps the team focused on its goal.
At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder.
The sprint ends with a sprint review and retrospective.
As the next sprint begins, the team chooses another chunk of the product backlog and begins working again
Customer collaboration over contract negotiation
In this context, customers can be internal colleagues, not just external. In any design process, there is always a danger that once a brief is agreed, the team then goes away and develops the prototype, only to find that it no longer meets the requirements of the ‘customer’. An Agile approach includes regular communication with the customer, to get his or her ‘buy-in’, so that once the product is developed, they know what to expect and have been involved throughout the development process. This can mean working with non-technical colleagues, perhaps in the product marketing department, on a level not experienced before.
Responding to change – over following a plan
Of course, solid planning is usually essential, however within that framework, Agile prescribes that it is important to be able to respond to change and be flexible. After all, when a project can take months or years to deliver, it is not surprising when market or customer requirements change.
Some deadlines, like manufacturing lead times, are hard stops in the schedule. Does that mean the project can’t respond to changing requirements? Quite the opposite. It means that, until the project hits that deadline, the team has to be as Agile as possible, embracing continuous delivery principles.
Agile – how SCM helps get it right
So far so good, but Agile can – and does – go wrong. Here are three pain points that organisations typically face and how version management (or software configuration management) system can help:
Latency – while the intention may be there, in practice it is easier said than done to prevent delays. One of the biggest bottlenecks can be retrieving source files from a repository or opening in dynamic views. Continuous integration (CI) can help address this, by ensuring that the software works at all times, not just as it is being released.
Far-flung teams – this is one that Agile didn’t see coming, at least at first. The movement emphasised co-location and collaborative programming, with daily-stand up meetings and shared workspaces. However, thanks to outsourcing, the need for differently skilled teams, particularly when building hardware and software products, and high-speed connectivity, vastly distributed development is now commonplace. Again, SCM can help support this, enabling distributed teams to keep track of what has happened and what is happening, collaborate with colleagues, but carry on working on their own projects.
Varied workflows – during the development process, multiple teams will be involved working on different elements and each team may have its own workflows. For example, the process used by the software development team is likely to be different to that used by the documentation team and the hardware design team. These teams will also be working on very different asset types – source code text files, large binary files for hardware designs or documentation PDFs. The best SCM systems should be able to handle all the different content types and workflows such that all teams work the way they want to and have visibility in all parts of the project.
Agile lessons from the games industry
The game development industry hit a number of the same roadblocks, yet many have been very successful with Agile methods, not least Perforce customers. Game developers are successful with Perforce because the tool actually increases collaboration and communication: a key Agile principle. SCM – or version management – lets the entire team, no matter the discipline, store and work with their data in a common repository.
Hardware engineers can manage their huge design files, while firmware engineers can work with their driver code, and the software developers can of course participate fully. Each team can work semi-independently, yet still make their work visible and useful to the rest of the shop early on. For example, a firmware engineer can always load the latest approved hardware simulator designs for testing.
Given that the cross-functional teams may not be at the same location and may use very different schedules and workflow, it is important to build communication into the tools and processes. The SCM system should lend itself to modern task management techniques, like task branching and pull requests. These processes improve quality and build communication into the way the organisation works.
Time to market has never been a more critical element of product development than it is today. Ensuring that products fit customer demand is what makes products profitable. Agile methods, particularly Scrum, offer a chance to address both challenges. A strong SCM tool is required to enable distributed, multi-skilled teams to fully exploit the promise of Agile methods.
Professional Software Development
Building a website wasn’t so easy earlier as it is now. Fortunately the time has passed when you had to hand-code HTML and PHP scripts in order to get an easy and fully functional website. Now content management systems (CMSs) do most or all of the heavy lifting for site creators. There are a number of CMSs for serious site creators, but the most common for websites today are considered to be three open-source tools: Joomla, Drupal and WordPress.
WordPress is a free and open source blogging tool and a CMS based on PHP and MySQL. It got its start as a blogging platform in May 2003 and gradually evolved, first into a blogging system that let users add Web pages outside of the blog and then into a full-featured, popular CMS. Of the three most popular open-source CMSs – WordPress, Joomla and Drupal – WordPress is both the most popular and the fastest growing by far, according to Web technology tracker W3Techs.
Earlier anyone could hardly think of using WordPress as the blogging platform. But now the situation has changed completely. Every second site owner using a CMS chooses WordPress. But to be objective let’s see what the facts are that speak in favor of this star-CMS. And what are there against it?
It means you get access to its source code and can study, modify and improve it according to your needs. However, it doesn’t mean you can do anything at all with the code. WordPress is issued under GPL license, which restricts certain actions (like limiting access to the code for others etc).
* Installation doesn’t cost anything
However, you may need to pay for customization, app development, premium themes etc, but the basic installation is at no cost.
* Easy set-up
That’s not even advertised anymore. It is simple and it is also quick. WordPress is known for 5- minute’s installation time.
* “Friendliness” with users
What can be a better way to gain popularity among users that become friends with them? WordPress is well suited for all types of users, even those who had never suspected a site can possibly have a backend. If you are able to google WordPress site and register your account, if you know how to use a text processor, you’re sure to get well with your new WordPress blog or website.
* No problems with customization
With the number of free themes and plug-ins for adding functionality to your site bigger than in any other CMS, a user gets the rich choice of website appearance and features that don’t come by default. And their integration is usually as easy as installing WordPress itself.
* Community support
WordPress has the enormously big community of users – from new born WordPressers to seasoned pros. They do great job helping each other via community support forums and discussion boards. Apart from that, WordPress provides exhaustive documentation on every possible issue, to ease the life of its followers.
* Multisite feature
WordPress allows its users not to be limited with just one website or start every new site with the new WordPress installation. With Multisite feature that’s available with all versions starting from WordPress 3.0 you can manage your several sites within one admin interface. However, to use this feature successfully, you need to study the WordPress codex well and have certain administration skills.
The security of WordPress leaves much to be desired, as with majority of open-source software. The thing is, when anyone gets access to the code, it’s easy to find flaws in it and use them to get into a site. But it doesn’t mean you’ve got to buy the most expensive software, you just need to use the techniques to enhance the protection of your site integrity.
– Advanced theming/features
If you know no HTML and coding and are satisfied with the looks of your blog by just switching to a new theme – you’ll be fine. If you desire to start off by changing everything to your taste – you may be in need for professional help. As to adding more functionality to your site via various plug-ins, in most cases, the common ones work out great, but if you experiment too much with them, you may get stuck when one plug-in is not compatible with the other, some need upgrade and some require tweaking the code to work correctly.
– Maintenance Costs
Although considered one of the most affordable CMSs, WordPress still may require money to be running successfully. For example, you pay for hosting, if it’s not self-hosted, exclusive themes or plug-in development in case nothing free suits you.
WordPress: what to expect?
During 2012, WordPress didn’t undergo any major changes. There wasn’t much new in WordPress 3.4 except easier theme customization. WordPress 3.5 had a mildly different new theme, some media improvements and not much else. In contrast, WordPress 3.6, which is set for a release sometime in April-May 2013 feels like a big step forward. There’s a bold new theme and several useful new features.
• Twenty Thirteen:
Twenty Thirteen will be the new default WordPress Theme with increasing support for post formats. Unlike previous default WordPress theme this theme is going to have lots of bold colors and will be fully responsive.
• Navigation Menus:
Lots of beginners complain that WordPress Menu system is quite hard to understand. In WordPress 3.6 this navigation menu options have been simplified and it will become easier to create and manage Menus in WordPress.
• WordPress Post Formats:
In WordPress 3.6 there will be a new User interface for Post Formats and theme authors will also have access to template the individual functions to change the structured data.
• WordPress Auto Save:
There will be some great enhancements related to Auto Save function. Posts are now auto saved locally so if the browser crashes, the server goes down or internet connection fails you will not lose the post and you will be able to resume editing right where you left it.
• WordPress Post Revisions:
Upcoming WordPress version will be a better handler for your post revisions. The changes will be highlighted with different colors so you can modify the usual things easily.
• Post Lock:
WordPress 3.6 will have a better editorial feature built in called Post lock. It will allow the authors or website administrators to lock a post to kick other person out of the editing and gambling between posts.
No site or platform is perfect, but WordPress has so much to offer and is very easy to use. In my opinion, the advantages outweigh disadvantages and with new version of it things are only getting better. Do you agree? Are there any other pluses and minuses of WordPress that are essential in your opinion and that I didn’t mention in the article? I’m eager to see your comments 🙂
Software-defined networking (SDN) is a hot, much debated topic and although still in its infancy, it offers the potential to transform how complex networks work. But don’t be fooled into thinking it’s only yet more industry hype, the era of Software Defined Everything is already upon us. Software is being applied to everything from servers, storage, data centres, right through to arguably the most ground-breaking piece of the jigsaw – the Wide Area Network.
SDN changes the way companies build their IT environments by essentially moving the “control plane” of the network away from each individual device in the network to a central controller that works with all the devices, both virtual and physical. This allows for a single controller to configure or manage the complete network, as opposed to each device managing its own functionality and being programmed individually. The technology has huge benefits for businesses, including reducing IT expenditure and enabling changes to the network quickly and easily.
The importance of the network
SDN deployments are still very limited and at their early stages of development. This is due in part to the fact that today’s corporate networks use open standards such as the IP protocol and Ethernet connectivity, but configuring the networks themselves often requires lots of manual tasks because each device on the network has separate policies and consoles. Making significant changes in the network – even with existing hardware – can be time-consuming, potentially taking a week or two. With the move towards server virtualisation and cloud computing, this has become even more complex.
With this in mind, it is no surprise that SDN is making its way to centre stage. SDN is being tackled from all sides of the ecosystem, from virtualisation vendors like VMWare to the traditional networking providers like Cisco. Not only is it going to fundamentally change the business models of the networking and server industries, but it is also going to escalate the importance of the network.
The value that SDN poses for businesses is immense. It holds greater potential for productivity increases from IT than any other development because of the way it acts as a unifying force between disparate elements – computing, networking, virtualisation, information, and business logic. There’s no doubt that SDN will be a disruptive force across cloud, carrier and enterprise networks, likely in that order. The natural progression of turning hardware into software will result in re-architected networks, data centres and infrastructures.
What the future holds
The integration of everything into the network will become a no-brainer in the coming year and this will essentially transform the network into the epicenter of ICT services. While no one can predict the SDN end-game, we are at the cusp of a revolution in the way global networks are designed, built, and managed.
By providing more real-time intelligence and deep application integration SDN is going to enable enterprises to realise innovation earlier with applications rolled out in hours instead of weeks. Organisations will achieve never-before-seen levels of agility while reducing both capital and operational overhead to the lowest levels ever delivered in enterprise solutions.
As a platform, SDN provides the potential to drive the next generation of IT services. Early high visibility adopters like Google and the recent significant increase in VC funding into the SDN area is fuelling momentum and the emergence of the era of Software Defined Everything looks set to change the power of the network for good. Organisations should be looking very seriously at how SDN can benefit their businesses before their competitors get there first.
Professional Software Development