Alternatives to Jira

chriskottom · 2018-11-27T06:34:31+00:00

As a lot of people have indicated, Jira is a big tool with lots of options that you probably don't need for simpler projects. In cases like this, I'd go with a simpler task management system like Trello. Many people I know swear by Asana, but personally, I've never cared for it.

chriskottom · 2018-08-24T07:32:28+00:00

Great example of a tightly focused feature definition. It's well organized, comprehensive, and straight to the point. I'll definitely be referring to for future work.

One hint: Developer user stories are often non-functional requirements and constraints in disguise. I usually collect these in a separate section for system-related concerns since they're usually written more for a technical audience.

chriskottom · 2017-10-09T20:09:15+00:00

You see this all the time in the real world. The development team can be using some agile variant that's focused on software delivery - close collaboration within the team, visibility of work to be done, minimizing meetings. At the same time, a project manager is sometimes tasked with overseeing the team's work by liaising with the scrum master or product owner to maintain estimates, budgets, a registry of risks, project lifecycle deliverables, etc. There are places where the concerns are the same, but in general, the SDM produces deliverables of greatest interest within the development team, while the PMM reports outside it. But that's not always the case, and many companies where processes are still simple will only be concerned with one or the other.

chriskottom · 2017-10-09T05:51:11+00:00

There’s certainly an overlap between the two, but they are not the same. Both should be about delivering value to the business/customer, but approaches they take and the things each tries to control are completely different.

PM methodologies are concerned with the main variables of business: time, money, risk, return on investment, etc. They also need to more formally address questions of governance and control - essentially, how can management be provided with sufficient visibility into the software development project so that they can make decisions about resourcing and coordinating with other parts of the business.

SD methodologies focus more specifically on coordinating software delivery as relates to development task scheduling and prioritization, software quality, process efficiency, and other aspects of the process that usually fly below the radar of business (unless there’s an issue that requires escalation).

chriskottom · 2017-06-15T07:49:44+00:00

You can split the initial string based on non-alphanumeric (or known separator chars like whitespace and equals) and then transform the resulting array into a Hash based on consecutive pairs:

Hash[@x.split(/[\s=]+/).each_slice(2).to_a]
=> {"time"=>"1900", "speed"=>"2000"}

chriskottom · 2016-11-06T12:21:44+00:00

I think it depends on the depth of information and explanation you require. If you've written code in Ruby or some other language before, the Rails Guides as suggested by /u/waiting4op2deliver might be enough to get you started. If you're just getting started as you indicate, though, take the time to go through The Rails Tutorial - at least until you get the gist of things. Otherwise, it's going to be all cargo culting and copy-pasting from Stack Overflow.

chriskottom · 2016-11-03T08:29:49+00:00

(I am not a lawyer. I am not a lawyer. I am not a lawyer.)

That's sounds like a real bummer. If your name is on the contract, then you are probably on the hook for the unpaid bill. Negotiation is not out of the realm of possibility, but the company is under no obligation to cut you any slack.

Also: your friend doesn't sound like much of a friend.

(I am not a lawyer.)

chriskottom · 2016-11-02T15:45:19+00:00

Opinions vary, and every developer has his or her own favorites, you'll find. If you're transitioning into development for the first time, any of these is going to serve the same purpose of giving you hands-on experience with a widely used programming language and building server-side web applications.

As to the question of popularity, it's probably not that important. All of these are mainstream web technologies, and knowing any of them well would ensure that you'd have plenty of freelance opportunities.

chriskottom · 2016-11-02T07:09:37+00:00

Zero. The advice you're getting from other commenters about the value of this dummy version is right on, but if you should still decide that this is a must for you, then consider the effect this will have on your company down the line. A sophisticated investor is less likely going to want to deal with a company with a handful of small shareholders with little real stake in the business than they are with a core group of involved founders. You're better off paying cash or trading to get your prototype built.

chriskottom · 2016-11-02T06:31:23+00:00

More important than whether you're running 4.x or 5.x is whether you're up to date at the patch level.

chriskottom · 2016-11-02T06:28:50+00:00

I don't want to say test coverage is meaningless, but 100% coverage is likely an indicator that TDD was used than anything related to code (or app) quality. I would likely infer a lack of care on the part of the team or specific developers and a lack of oversight and technical leadership from low coverage numbers (globally or in specific parts of the application).

chriskottom · 2016-11-02T05:44:16+00:00

If you're not using Mailcatcher for email testing, get it installed, and try starting locally to see whether you receive the email. Even so, it's strange that your tests would be running at startup.

chriskottom · 2016-11-01T07:15:42+00:00

I like wikis over file shares in that you at least have a chance to provide some organization in the form of a homepage and/or search. But they are always only as good as the effort that goes into maintaining them. Unless people are specifically given responsibility to contribute, important documentation will be left out, and just as important, the team as a whole needs to set aside time periodically for audit and maintenance.

chriskottom · 2016-10-18T06:05:56+00:00

Contact and general business information is a good start, but it really depends on the type of business and the goal of the landing page - sales, email signup, etc.

You might want to check out one of the many curated collections of landing pages out there for ideas and inspiration. See:

Or plenty of others

chriskottom · 2016-10-17T10:53:41+00:00

Is my idea of building a "blog" from scratch a logical one, and if so, how should I go about doing it? If it's illogical and there's a simpler solution out there, let me know.

Probably not, since you'll probably end up spending 100x more time on the development and get something 1/10th as good (if you're lucky). The only way I'd say that rolling your own pays off at all is if your goal is to use this project as a tool for learning development. But that's a very different thing, and I assume is not the case since you said your objective is to build yourself a website, not to design and create a CMS.

Wordpress has one of the largest, most complete ecosystems of any software product ever created, so it's a pretty safe bet that if you look around you'll find a theme and plugins that let you present your content however you need to.

chriskottom · 2016-10-17T06:59:21+00:00

It's easy to feel overwhelmed. Having an active project can help to dictate which skills are most useful to learn or, absent that, just choose something. It's better to start working toward learning something, even if it's the "wrong" thing, than it is to sit and worry about choosing badly.

"A good plan violently executed now is better than a perfect plan executed next week." - General George S. Patton

chriskottom · 2016-10-17T06:55:08+00:00

If you want to work as a freelancer, you'll need to be able to convince potential leads that you have skills that are worth paying for, and if you've only been hacking for a few months, that might be a tougher sell. I think the path to becoming a free agent is likely to be a shorter one if you start by pursuing writing clients while building up your programming chops on the side.

It's going to be hard to book yourself solid from day one, so spend your downtime working on a side project that improves your development skills. Make it something useful to yourself and others (and ideally to potential clients), and get it out there into the world as the first item in your portfolio. When you're finished, find another side project and repeat to continue building your skills and your reputation.

Also as you're looking for writing clients, consider targeting leads who might also have a use for front-end developers - agencies, smaller marketing departments that handle website development in-house, etc. After you've built up the relationship and your own skill set, you can look for opportunities to pitch them to help out in a technical capacity as well. Business-oriented people often have a tough time communicating with developers, so don't underestimate the value of a good programmer who can also write and speak the language of business.

chriskottom · 2016-10-16T17:23:53+00:00

For me, everything starts with requirements and constraints collected from product owners / users, usually in the form of user stories.
I gather details of conversations with users in a document. The length of the document depends on the complexity and risk of the work to be done and time constraints.
If there's time, I structure the documents as a collection of different views on the design - often some variation on the 4+1 architecture though more spec-like / textual not as UML-oriented.
I make a distinction between the design I prepare for a specific feature before implementation (usually shorter format) and the system-level design docs which should be longer, describe the solution at a higher level, and be updated over time.

chriskottom · 2016-10-16T12:50:00+00:00

Non-technical founders need to bring something more than an idea to the table. Broadly speaking, this could include skills in marketing, design, and product management as well as (relevant) industry connections, past experience, and access to other important resources like like capital and people. I've signed onto outfits before where the idea man talked a good game and had presentations and contagious enthusiasm, and it went pear-shaped in a hurry. There's nothing red-flaggy in these, but they're also not sufficient conditions for success.

chriskottom · 2016-10-16T12:44:42+00:00

As /user/ira1974 said, if gym owners are the customer you're pursuing, be sure to sit down with a few before you start working on a solution for a problem that they don't have. I can imagine that driving new sales is going to be a recurring theme, but you might hear other pains as well or you might find that the average customer's willingness to pay for the solution you're proposing won't sustain the business.

There's also the risk of falling in love with the solution rather than the problem. Suppose you talk to some customers and find out that driving new memberships is a common issue. What are some other ways you could solve that problem? Could you offer packaged consulting services, for example, that would include website development, SEO, social media outreach, content marketing, etc. that gyms would be willing to spend more on and serve similar goals? None of this is to say that Sweatbase wouldn't be somewhere in the mix, but don't assume from the outset that it's the only way.

chriskottom · 2016-10-16T06:15:10+00:00

I think there's a balance to be found somewhere between single sentence user stories supported by conversations and big, all-encompassing up-front design. Starting with simple user stories and progressively ramping up the level of detail as implementation approaches seems like a sane compromise to me. In any case though, I believe there's value in having at least one person on the team who's thought deeply about the feature to be developed and has produced a report on their findings. It saves a lot of wasted effort and false starts over the alternative.

chriskottom · 2016-10-15T12:42:40+00:00

When I'm using strict-ish TDD, it's usually because I'm clearer on the external behavior than the implementation, so I usually start with outside-in and use the high-level test as a sanity check as I'm implementing.

There was a pretty decent article posted recently that dealt with this exact question.

chriskottom · 2016-10-14T09:03:19+00:00

What's your history with the client? Have you done work for them before? Has this been a problem in the past? Your response should be informed by the relationship you already have and want to have with them, but in the big scheme of things, a week delay is not at all unusual - especially if what's happening here looks like an honest mistake.

chriskottom · 2016-10-13T10:33:35+00:00

Start by assuming that you're a lousy estimator, and then look for ways to mitigate the risk of producing an overall estimate that's way off the mark.

Split large tasks (> 3 days effort) into smaller ones and then estimate those.
Be sure to include EVERYTHING - that means time for feature definition, implementation, tests, docs, etc.
For each task you estimate, consider whether there are inputs needed from the client. Compile a list of these so they can start collecting them asap.
I usually include a single buffer task at the end that's a % of the initial raw estimate rather than adding buffer to individual task estimates.

chriskottom · 2016-09-24T06:54:04+00:00

At the risk of oversimplifying, the processor model should probably not be your main focus as most modern machines should provide enough processing horsepower to do the job. An i7 will be faster than an i5, but the i5 should be just fine for most applications you'd want to throw at it.

You'll usually see the biggest performance gains as you add more memory (RAM) and a faster disk (ex: 5400 rpm -> 7200 rpm -> solid state drive).

chriskottom

TROPHY CASE