Managing

The team’s development process defines who does what, when, and how. Waterfall – activities proceed through a fixed sequence, each step depending on the previous one. Spiral – starts with risk-driven prototypes, then follows a structured waterfall-like process. Iterative – a hybrid that decouples lifecycle phases from the activities within each phase. Whichever model you choose, build at least one early prototype to get customer feedback before committing to a full implementation.

Some people believe the best way to estimate a project is to produce detailed requirements and design documents for every feature before writing a line of code. It sounds professional. It sounds thorough. In practice, it usually turns out to be wrong. Requirements change. Priorities shift. The detailed estimate you spent weeks producing becomes irrelevant halfway through the project. That effort becomes wasted inventory – time and resources that could have been spent building something useful instead. ...

In many projects, in order to provide a reasonable probability of success, it will be necessary to reduce the scope by as much as a factor of two. I’ve learned this the hard way. Every project starts with an ambitious list of features and an optimistic timeline. Reality intervenes quickly – resources are tighter than expected, technical problems emerge, and deadlines don’t move. Cutting scope feels like failure. It’s the difference between shipping something that works and shipping nothing at all.

Every piece of software I’ve developed elicits the same two reactions when users see it for the first time: First: “Wow, this is cool. We can really use this.” Then, immediately: “Yes, but… now that I see it, what about this? Wouldn’t it be nice if…? Whatever happened to…?” The “Yes, But” syndrome is universal. It comes from the nature of software as something intangible – until users see it, they can’t fully articulate what they need. Seeing the implementation triggers new ideas, new concerns, new requirements that weren’t visible before. ...

Software development is a complex and collaborative process that requires effective teamwork and communication. However, many software teams struggle with productivity issues and fail to deliver high-quality products on time and within budget. In this post, I will discuss why team productivity is more important than individual productivity, and how you can improve your software team’s performance by applying some proven strategies and best practices. The Importance of Team Productivity According to Boehm, the COCOMO cost estimation model shows that the capability of the team has the greatest impact on software production. This means that the quality and efficiency of the software product depend largely on how well the team works together. Davis agrees with this conclusion and states that “optimising the productivity of all individuals does not necessarily result in optimising the productivity of the team”. In other words, having a team of highly skilled and productive individuals does not guarantee a successful software project. There are other factors that affect team productivity, such as communication, coordination, collaboration, motivation, and trust. ...

Scrum breaks a product into small pieces (backlog items) and works on them in short iterations (sprints). Here’s how it works in practice: 1. Prepare the product backlog. List the features and requirements. Involve stakeholders to prioritise. The product owner is responsible for the vision and goals. 2. Estimate the backlog. As a team, give a rough estimate for each item. Planning poker or t-shirt sizes work well here. 3. Plan the sprint. A sprint is a fixed period – usually one or two weeks. In the sprint planning meeting, decide the duration, goal, which backlog items to tackle, the tasks for each item, and the hours per task. The result is the sprint backlog. ...

A degree gets you noticed. What you’ve done since then gets you hired. Here are some ways to show continuous learning on your resume: Professional certifications. They demonstrate you’ve met industry standards and can help you stand out from candidates with similar qualifications. Publications and articles. Writing shows you have something to say and can communicate it clearly. Use them as portfolio samples. Presentations. Speaking at universities, schools, or conferences demonstrates communication skills. Record them and post them online. Volunteer work in your field. Shows genuine interest in your work beyond paid employment. Technical courses and training. List them alongside formal education. IT certifications. Microsoft, Cisco, and similar credentials prove specific technical competence. Many employers look for them. Foreign languages. Learning another language opens doors and shows cultural awareness. Rosetta Stone and subtitled DVDs are good starting points.

Every programmer knows the urge: scrap everything and rewrite it from scratch. It’s not that the existing code is bad. It’s that it’s hard to understand. Reading code is harder than writing it – you wrote the new code in your head, but the old code belongs to someone else (or to past you, who might as well be someone else). This is why every developer on your team has their own favourite way of splitting strings into arrays. Writing a new function is simpler and more enjoyable than learning how the existing one works. ...

This is the process I follow on projects. It’s not fancy, but it works for me. Defining the requirements. Write down what needs to be built. Be specific. Ambiguous requirements are the root cause of most problems later on. Approval. Get sign-off on the requirements before anything else. If the requirements change later, that’s fine, but do it deliberately, not by accident. Template designs. Work out the structure and layout before writing code. For web projects this means mockups and wireframes. For other projects it means architecture diagrams and data models. Template approval. Get the designs signed off too. It’s cheaper to change a design than to change code. Coding. Build it. Internal release. Get it in front of the team first. Internal testing catches the obvious stuff before anyone external sees it. Testing. Proper testing, not just “I clicked through it once.” Automated tests where possible, manual where necessary. Alpha release. Early access for a small group. Expect bugs. The goal is to find them in a controlled environment. Beta release. Wider release. More users, more edge cases. This is where you learn what people actually do with the software versus what you thought they’d do. Project goes live. Production. The real world. The key thing is not to skip steps. I’ve seen projects that jump straight from requirements to coding and then spend three times as long fixing problems that a proper design phase would have caught.

I spent some time at Arsin Corporation, a company based in Hyderabad, India that specialises in enterprise software testing. Here’s a summary of what they do, mostly for my own reference. What they do Arsin provides automated testing services for large companies, with a particular focus on SAP. They’ve been around since 1995 and their clients are mostly Fortune 500 companies in pharmaceuticals, finance, healthcare, and technology. The idea is that when you’re running enterprise software, you can’t afford for it to break. Arsin builds the testing infrastructure that catches problems before they reach production. ...